Hi all,
I think both issues (pool size and using the old options) should be easily fixable. In fact, I would have expected using the old options to have worked, since we did just that with our original code before bringing it into shape for the eclipse.org contribution - I'll check up on that. I'm on the road today, but I have a free day tomorrow to look into it. Carsten -- +49 (0)69 2475666-33 | reck...@yatta.de<mailto:carsten%20reckord%20%3creck...@yatta.de%3e> | www.yatta.de<http://www.yatta.de/> Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt a.M. (Germany) Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director Johannes Jacop ________________________________ From: cross-project-issues-dev-boun...@eclipse.org <cross-project-issues-dev-boun...@eclipse.org> on behalf of Scott Lewis <sle...@composent.com> Sent: Tuesday, May 28, 2019 4:20:57 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform Filetransfer providers may be disabled at start time via a system property [1]. [1] https://wiki.eclipse.org/Disabling_Apache_Httpclient45 On 5/28/2019 12:54 AM, Daniel Megert wrote: But wouldn't that mean that (affected) clients have to change their code? Dani From: Scott Lewis <sle...@composent.com><mailto:sle...@composent.com> To: Daniel Megert <daniel_meg...@ch.ibm.com><mailto:daniel_meg...@ch.ibm.com>, Cross project issues <cross-project-issues-dev@eclipse.org><mailto:cross-project-issues-dev@eclipse.org> Date: 27.05.2019 23:13 Subject: [EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> ________________________________ On 5/27/2019 6:52 AM, Daniel Megert wrote: Hi Scott I assume that shipping the older httpClient version in addition, would not resolve those issues and that it is something that would have to be changed/fixed in ECF. Correct? I believe that the older provider (httpclient4) would resolve these issues as this provider has configurable timeouts...for connect and others. It would also be helpful to enlist the support of the httpclient45 provider author (Carsten) via [1] specifically around connect timeouts. Perhaps something can be changed in the new provider to handle the timeouts more like the older provider. Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=544447 Dani From: Ed Merks <ed.me...@gmail.com><mailto:ed.me...@gmail.com> To: cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> Date: 27.05.2019 15:19 Subject: [EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> ________________________________ FYI, I've run into a number of problems with the latest ECF/httpclient code. Mostly my own fault for how I've hacked ECF to be able to collect and submit cookies (so I deserve to suffer). :-P But also other problems. For example, the older timeout properties not being respected in the newer implementation, i.e., the properties from org.eclipse.ecf.filetransfer.IRetrieveFileTransferOptions for timeouts are not applied when using the new implementation where the default timeout is 120 seconds, so that can have a bad impact if your application runs into timeouts and has tried to limit the overall time impact using these options. But worse, the setup archiver application has basically stopped functioning with timeouts such as the following: FAILED to load http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup ERROR: org.eclipse.oomph.util.IOExceptionWithCause: Timeout waiting for connection from pool: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup0 0 0 After much investigating I fear that the Apache pool implementation is perhaps buggy (or perhaps how ECF uses it). ECF itself increases the pool's limit in org.eclipse.ecf.internal.provider.filetransfer.httpclient45.ECFHttpClientFactory.newClient()asfollows (so instead of 2 and 20). builder.setMaxConnPerRoute(100); builder.setMaxConnTotal(300); And while these numbers seem relatively large, the setup archiver visits a great many resources on multiple threads (to produce the setups.zip used by the installer). Only by increasing these numbers dramatically does the setup archiver application go back to normal functioning, completing in 19 second on the build server versus thrashing for 20 minutes and failing with connection pool timeouts. So in the end, I'm a little concerned because p2 also uses ECF to access repositories and if there is a problem with the connection pool refusing to hand out new leases even when the client has finished with the older connections, that could cause bad problems with updates and in the installer's ability to install, though fortunately a normal install will only access two simple repositories. But in the real world, people have very complex target platforms and very complex installations that reference horribly bloated composites. In these scenarios I have already seen connection pool timeouts... On 22.05.2019 05:57, Manoj Palat wrote: Hi All, Please note that platform has moved to latest ECF that includes httpclient45 (org.eclipse.ecf.filetransfer.httpclient45.feature). However, ECF (which is available at the update site: https://download.eclipse.org/rt/ecf/snapshot/site.p2) has both httpclient4and httpclient45. Platform mirrors httpclient45 (org.eclipse.ecf.filetransfer.httpclient45.feature) only from now on - essentially httpclient4.feature (org.eclipse.ecf.filetransfer.httpclient4.feature) and httpclient4.ssl.feature (org.eclipse.ecf.filetransfer.httpclient4.ssl.feature) are not mirrored to platform repository anymore. Requesting downstream projects to adjust their dependencies accordingly. Regards, Manoj _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
