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>
To: 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
------------------------------------------------------------------------
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@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
_______________________________________________
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