Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

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.setup 0 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() as follows (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 httpclient4 and 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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top