Thanks a lot for the valuable insight. I have included the httpclient based ecf provider in our app, but I've used a very old version I guess. Following are the ecf related bundles in the system.
id State Bundle 48 ACTIVE org.eclipse.ecf_3.1.300.v20110531-2218 49 ACTIVE org.eclipse.ecf.filetransfer_5.0.0.v20110531-2218 50 ACTIVE org.eclipse.ecf.identity_3.1.100.v20110531-2218
51 ACTIVE org.eclipse.ecf.provider.filetransfer_3.2.0.v20110531-2218 52 ACTIVE org.eclipse.ecf.provider.filetransfer.httpclient_1.0.0.v20070627-1030 82 ACTIVE org.eclipse.equinox.p2.transport.ecf_1.0.100.v20110902-0807
Maybe I should upgrade the httpclient-based provider to the latest stable. I couldn't do it immediately using org.eclipse.ecf.provider.filetransfer.httpclient_4.0.200.v20120504-2322 due to import version mismatches with the org.apache dependencies exported from the other bundles in the system. I will integrate this, by clearing out the import/export versions of org.apache dependencies and try to reproduce the same error.
just fine using the httpclient 3.1-based provider (i.e. that's the
one p2/Eclipse uses by default).
I can see from the below that you are not using the httpclient-based
provider (i.e.
org.eclipse.ecf.provider.filetransfer.retrieve.UrlConnectionRetrieveFileTransfer
is the UrlConnection-based provider). In general we've found the
httpclient-based provider to be more reliable...and put more effort
into making it more reliable...because that's what Eclipse/p2 are
using. You can use the httpclient-based provider if you wish in
your own application (you just need to include a few more plugins).
Now, about the error you are seeing in the UrlConnection-based
provider...I tried retrieving this url:
and it retrieved it without any exceptions in three ECF filetransfer
test runs. So in other words, it seems I can't immediately
reproduce the problem you are experiencing with this URL (I did
artifacts.jar rather than content.jar because right now I'm on a
slow link).
It is quite possible, then, that what you are experiencing is due to
some difference in system/configuration...it could be any one of:
1) Difference in java version (because it's using UrlConnection, the
underlying socket handling code is different)
2) Difference in OS (maybe there's some lower-layer problem with
Sockets on your system)
3) The java configuration (e.g. timeouts set very low)...i.e. the vm
defines these as defaults for connect and read timeout
and the org.apache dependencies (o.a.commons.httpclient,
o.a.commons.logging, and o.a.commons.codec)
If that doesn't/can't work out, then I'm willing to help you figure
out what's going wrong with the urlconnection-based provider...but
the first thing to do there is to figure out why I can't reproduce
what you are experiencing.
Thanks,
Scott
On 5/17/2012 12:33 PM, Dileepa Jayakody wrote:
Hi Guys,
We use equinox p2 as our provisioning platform. We also use
ecf.transport to stream remote p2 Repositories.Recently I came
across the below error [1] when trying to add a remote P2
repository.
It complains about a socket time out, at
org.eclipse.ecf.provider.filetransfer.retrieve.UrlConnectionRetrieveFileTransfer.getDecompressedStream(UrlConnectionRetrieveFileTransfer.java:542).
However this error is thrown within a minute trying to add the
repo, so I doubt if it's really due to a socket time out.
The error is intermittent & can be reproduced on a Windows
machine more frequently than on Ubuntu.
Any idea what's going wrong here? Could this be dependent on the
network configurations of the particular machine or OS (firewall,
virus guard etc)?
Appreciate any thoughts/tips to find the root cause of this.
[1] Error stack-trace
Caused by: org.eclipse.equinox.p2.core.ProvisionException:
Unable to read reposi
