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.merks@xxxxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx
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-bounces@xxxxxxxxxxx
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()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 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@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_______________________________________________
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
|