Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
Hi all, I think both issues (pool size and using the old options) should be easily fixable. In fact, I would have expected using the old options to have worked, since we did just that with our original code before bringing it into shape for the eclipse.org contribution - I'll check up on that. I'm on the road today, but I have a free day tomorrow to look into it. Carsten -- +49 (0)69 2475666-33 | reck...@yatta.de<mailto:carsten%20reckord%20%3creck...@yatta.de%3e> | www.yatta.de<http://www.yatta.de/> Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt a.M. (Germany) Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director Johannes Jacop From: cross-project-issues-dev-boun...@eclipse.org on behalf of Scott Lewis Sent: Tuesday, May 28, 2019 4:20:57 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform 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 <mailto:sle...@composent.com> To:Daniel Megert <mailto:daniel_meg...@ch.ibm.com>, Cross project issues <mailto:cross-project-issues-dev@eclipse.org> 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-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> 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 <mailto:ed.me...@gmail.com> To: cross-project-issues-dev@eclipse.org<mailto: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<mailto: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.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
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
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 To: Daniel Megert , Cross project issues 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-boun...@eclipse.org 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 __ <mailto:ed.me...@gmail.com> To: _cross-project-issues-dev@eclipse.org_ <mailto: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-bounces@eclipse.org_ <mailto: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()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 /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
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
Dani, Note that I've commented on the bug with details. Hopefully someone will find time to look at the pool problem, which is the most serious. To set the timeouts I did have to change code but perhaps the new implementation will/could be changed to respect the older options. In any case, it's probably best for any further discussions by interested parties to do so in the Bugzilla. Regards, Ed On 28.05.2019 09:54, Daniel Megert wrote: But wouldn't that mean that (affected) clients have to change their code? Dani From: Scott Lewis To: Daniel Megert , Cross project issues 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-boun...@eclipse.org 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 __ <mailto:ed.me...@gmail.com> To: _cross-project-issues-dev@eclipse.org_ <mailto: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-bounces@eclipse.org_ <mailto: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()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 /httpclient4/and /httpclient45/. Platform mirrors /httpclient45 /(org.eclipse.ecf.filetransfer.httpclient45.feature) only from now on - essent
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
But wouldn't that mean that (affected) clients have to change their code? Dani From: Scott Lewis To: Daniel Megert , Cross project issues 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-boun...@eclipse.org 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
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
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_ <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-p
Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
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
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
[cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform
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
