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
loadhttp://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@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
