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