Community
Participate
Working Groups
CompositeMetadataRepository.createMemoryComposite creates in-memory composite repositories using a "memory:" url. Attempting to use a index file with this kind of repository results in the following exception. This came out in a PDE/Build log, it doesn't seem to actually hurt anything. [p2.artifact.mirror] !MESSAGE Connection to memory:1305143612825/p2.index failed on unknown protocol: memory. Retry attempt 0 started [p2.artifact.mirror] !STACK 0 [p2.artifact.mirror] java.net.MalformedURLException: unknown protocol: memory [p2.artifact.mirror] at java.net.URL.<init>(URL.java:586) [p2.artifact.mirror] at java.net.URL.<init>(URL.java:476) [p2.artifact.mirror] at java.net.URL.<init>(URL.java:425) [p2.artifact.mirror] at java.net.URI.toURL(URI.java:1092) [p2.artifact.mirror] at org.eclipse.ecf.provider.filetransfer.identity.FileTransferID.getURL(FileTransferID.java:76) [p2.artifact.mirror] at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:881) [p2.artifact.mirror] at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) [p2.artifact.mirror] at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:349) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:295) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:80) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:130) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadIndexFile(AbstractRepositoryManager.java:718) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:640) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.doCreateRepository(AbstractRepositoryManager.java:272) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.createRepository(MetadataRepositoryManager.java:41) [p2.artifact.mirror] at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository.createMemoryComposite(CompositeMetadataRepository.java:71)
I see this in my logs after some PDE exports from the UI: ProductExportOperation.run(ProductExportOperation.java:106) PW
I'm wondering if this could be related to the consumption of the new ECF. Could you please try with an older build (M5 / M6) and see if you get the same error?
I tried the M6 build, I20110310-1119, and an RCP Mail product export doesn't produce any logs. The same RCP Mail product export on I20110526-0800 produces these logs. PW
Scott, the occurrence of this problem seem to match with the update to ECF 3.5.1. Does that ring a bell?
Setting for RC4 for investigation.
(In reply to comment #4) > Scott, the occurrence of this problem seem to match with the update to ECF > 3.5.1. Does that ring a bell? No, not really. I don't understand why/how 'memory' protocol URLs are used...without some sort of URL protocol handler registered.
memory: protocol is just a URI trick that p2 plays to create repositories in memory w/o ever needing to write them to disk. Therefore we should never have to hit the file system.
(In reply to comment #7) > memory: protocol is just a URI trick that p2 plays to create repositories in > memory w/o ever needing to write them to disk. Therefore we should never have > to hit the file system. I see. I would not expect, then, that the transport would ever be consulted in the 'memory' protocol case...i.e. why is a download attempted at all when using the 'memory' protocol? Perhaps it was/has been this way, but the generalization that was introduced in ECF last fall (support for arbitrary URIs) simply expose this via the exception.
Created attachment 197041 [details] Patch I've traced that down and the ECF code is logging the exception whereas it did not to and this causes the noise in the log (see class FileReader#checkException(...)). I'm not sure if this exception should be logged there (or maybe only logged in debug mode). While reviewing the ECF I also noticed that the call of checkException in readInfo does not check the return value. At this point, to avoid shipping with noise in the log, I have added a patch that prevents ECF to be called for memory repositories.
While the log noise is certainly an issue, I am not convinced this is a critical issue to consider for RC4. Definitely something to consider for 3.7.1 though.
Actually the error is not only in the eclipse log but also when you execute ant tasks (see first message) and this is definitely scary since it is in your build output. This will scare ppl and they will ask a lot of questions, open bugs, etc...
I've seen this too. I wonder if this is just a problem with the p2.index file, or are there other places we would have consulted ECF for memory:// URIs? In any event, the fix seems reasonable. Now, instead of consulting ECF for memory:// URIs we short circuit and return an empty p2.index file (it doesn't really make sense in that case anyways). I agree with Pascal, in our current state we are going to scare a lot of people.
+1
This has been released. Thx everybody.
