Community
Participate
Working Groups
Build Identifier: 20100218-1602 Maybe a duplicate of #299444, but since I did not debug eclipse to find out more, I am not sure. When using the update manager to get new plugins,it seems any download of a plugin jar greater than 4-5Mo leads to the following error (or similar) : !ENTRY org.eclipse.equinox.p2.engine 4 4 2010-05-19 09:31:11.383 !MESSAGE An error occurred while collecting items to be installed !SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2010-05-19 09:31:11.383 !MESSAGE session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). !SUBENTRY 1 org.eclipse.equinox.p2.repository 4 1002 2010-05-19 09:31:11.383 !MESSAGE Unable to read repository at http://downloads.sourceforge.net/eclipse-cs/com.atlassw.tools.eclipse.checkstyle_4.4.3.jar. !STACK 0 java.io.InterruptedIOException: Timeout while reading input stream at org.eclipse.ecf.provider.filetransfer.util.PollingInputStream.read(PollingInputStream.java:161) at java.io.FilterInputStream.read(Unknown Source) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer$1.performFileTransfer(AbstractRetrieveFileTransfer.java:161) at org.eclipse.ecf.filetransfer.FileTransferJob.run(FileTransferJob.java:74) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) During the whole update process, I can see the small jars properly downloaded. The "big" jars seem to be properly downloaded, but for an unknown reason, it fails at the very end of the download process. My company runs a proxy. It is set as "native" in eclipse. I tried to download one of the problematic jars with firefox. It works properly, but just before it finishes the download, it pauses for an unknown reason several seconds before finishing properly. The file is then readable and contains everything it is intended to contain. What I am supposing is the following: the proxy is blocking the last chunk of the file for an internal process (maybe an antivirus analysis), and p2 times out during that "tiny" interval. I suggest adding a timeout preference to handle an abnormally long pause from the proxy (or anything else) AFAIK, this problem affects last galileo release (fully updated) and helios M7 (last one I tried). It did not happen before a week or so: something must have changed in the proxy configuration but I do not think the issue should be dealt on the proxy since firefox handles it flawlessly. I file it as Major since I am unable to get any new meaningful plugin as of now. Reproducible: Sometimes Steps to Reproduce: Seems to happens when one of the downloaded jars are big enough.
Do you notice a delay at the end of the download when you use firefox? Could you please try to gather the details of your proxy settings and also figure out what has changed? Scott, is it possible to increase the timeout to see if it helps?
Hi Jean, Based upon your stack trace, I believe you are using the ECF UrlConnection provider rather than the httpclient-based provider...possibly because you are behind an NTLMv2 proxy. In this case, the PollingInputStream has a default read timeout of 1 second...and the PollingInputStream has a default of 20 retries (for total of 20 seconds). It is possible, however, to change these values by using System properties: org.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=1000 org.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=20 (for completeness, there is also a close timeout value) org.eclipse.ecf.provider.filetransfer.retrieve.closeTimeout=1000 You can change these values by specifying alternatives on the Eclipse command line...e.g. eclipse.exe -vmargs -Dorg.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=5000 Would you be able to try out a larger read timeout value in your environment and see if this has a positive effect for you?
(In reply to comment #2) < [...] > In this case, the PollingInputStream has a default read timeout of 1 > second...and the PollingInputStream has a default of 20 retries (for total of > 20 seconds). It is possible, however, to change these values by using System > properties: > > org.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=1000 > org.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=20 I'll try that. Apparently, the threshold has evolved on the proxy, the timeout is shorter and some more heavy jar downloads succeed. If the antivirus hypothesis was right (I still do not know), it could be explained by lesser load on the antivirus server ... I'll try to investigate further, but the 20 times 1sec seem to fit what I experienced here. > (for completeness, there is also a close timeout value) > org.eclipse.ecf.provider.filetransfer.retrieve.closeTimeout=1000 I had an other issue, not listed in my initial post since it happened less that involved closing the inputStream. However, I have no stacktrace related to that one (I might have wiped out the log since) If I can reproduce it, I'll try changing that property as well and add the stack trace here.
(In reply to comment #1) > Do you notice a delay at the end of the download when you use firefox? Yes > Could you please try to gather the details of your proxy settings and also > figure out what has changed? It's going to be difficult, the IT here does not like proxy related questions, even founded ones :) Besides I never ran into any proxy related issue until now.
Ok, I got it to work by raising the inputStream read timeout to 10 sec. So, I'll stay with that setting for now. I am not sure this should go in the preferences. However, maybe it would be a good idea to add a pointer to the solution in the error message, so that anyone encountering the issue had, at least, some insight into a possible explanation. Anyway, thx ... If you think this issue should be considered invalid, feel free to close it, I'll reopen it if I find anything worth it.
Moving to ECF that owns the message.
I've added a detailed message (about available system properties) for the read and close timeouts for the urlconnection-based provider. Just for all info: the httpclient provider does not use the PollingInputStream, so has different params. I also increased the number of 1s retries to 30 (from 20) in order to help avoid this situation a little. resolving as fixed. Pascal, please let me know when you want a new integration build (i.e. asap for RC2?). I can produce it relatively easily (this is the only change since RC1). Thanks Jean for report.
(In reply to comment #7) > I've added a detailed message (about available system properties) for the read > and close timeouts for the urlconnection-based provider. Just for all info: > the httpclient provider does not use the PollingInputStream, so has different > params. > > I also increased the number of 1s retries to 30 (from 20) in order to help > avoid this situation a little. Thx for the quick replies > [...] > Pascal, please let me know when you want a new integration build (i.e. asap for > RC2?). I can produce it relatively easily (this is the only change since RC1). > > Thanks Jean for report. I am using eclipse since version 0.9, I'm glad I finally contributed a bit.
If you want to go through a build I will consume it. But I'm not in a hurry to get this fixed. So it really depends on you.
(In reply to comment #9) > If you want to go through a build I will consume it. But I'm not in a hurry to > get this fixed. So it really depends on you. I would rather get off my plate so other things can be addressed...so I will produce a new build with this fix today/Friday and notify in usual places.
