Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

[Scott Lewis]

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=57




Dani



From: Ed Merks 
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_ 

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

Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

[Daniel Megert]

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?

Dani



From:   Ed Merks 
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
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=dqIUNOXGZt_oKwGG0POYBQNZkzR0qgfAiI7su_Cv-UQ=GRV9AEFxsHC-HW-_p7T1LhJNeJ_YEdRiRowGlj0BAeM=



___
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

Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

[Ed Merks]

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

Re: [cross-project-issues-dev] Slow git https access via https://git.eclipse.org/r/?

[Matthias Sohn]

On Mon, May 27, 2019 at 10:02 AM Matthias Sohn 
wrote:

> On Mon, May 27, 2019 at 9:45 AM Andrey Loskutov  wrote:
>
>> Hi,
>>
>> I'm only one who has a problem to pull from git.eclipse.org via https?
>>
>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547671
>
>
> I can't fetch from Gerrit anymore since yesterday and filed bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=547666
> to track this
>

fetching from Gerrit via ssh seems to work
___
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

Re: [cross-project-issues-dev] Slow git https access via https://git.eclipse.org/r/?

[Matthias Sohn]

On Mon, May 27, 2019 at 9:45 AM Andrey Loskutov  wrote:

> Hi,
>
> I'm only one who has a problem to pull from git.eclipse.org via https?
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547671


I can't fetch from Gerrit anymore since yesterday and filed bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547666
to track this

-Matthias
___
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] Slow git https access via https://git.eclipse.org/r/?

[Andrey Loskutov]

Hi,

I'm only one who has a problem to pull from git.eclipse.org via https?

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547671

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

___
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