|
Filetransfer providers may be disabled at start time via a system
property [1].
[1] https://wiki.eclipse.org/Disabling_Apache_Httpclient45
On 5/28/2019 12:54 AM, Daniel Megert
wrote:
But wouldn't
that
mean that (affected) clients have to change their code?
Dani
From:
Scott
Lewis <slewis@xxxxxxxxxxxxx>
To:
Daniel
Megert <daniel_megert@xxxxxxxxxx>, Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
27.05.2019
23:13
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
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()asfollows
(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
_______________________________________________
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
|
