Bugzilla – Full Text Bug Listing
| Summary: | Suggest reference to the ECF system properties in the error message | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Jean Couillaud <carm> |
| Component: | ecf.filetransfer | Assignee: | ecf.core-inbox <ecf.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | carm, pascal, slewis |
| Version: | 3.2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Jean Couillaud
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. |