Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Ed Merks-2

Hi,

I don't know how many of you have noticed things like this in the build logs:

12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute
12:25:45 INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute
12:25:45 INFO: Retrying request to {s}->https://download.eclipse.org:443

I'm a bit concerned about the cause of such exceptions.  I've debugged where this happens in my Oomph environment.  Specifically it happens in org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when parsing the response header finds nothing with the following stack leading to the logged problem:

org.apache.http.NoHttpResponseException.<init>(java.lang.String) line: 47   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 141   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 56   
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser<T>).parse() line: 259   
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() line: 163   
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157   
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 273   
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 125   
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 272   
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 186   
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 89   
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 110   
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) line: 185   
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, org.apache.http.protocol.HttpContext) line: 83   
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() line: 246   
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) line: 69   
org.eclipse.core.internal.jobs.Worker.run() line: 63   

There will be two additional retries, and if those fail too, the repository will fail to load (or the artifact will fail to download).   In my product catalog generator, I load a whole whack of repositories and this happens frequently enough that more often than not, one or more repositories fail to load.  This concerns me because with 2 million users loading repositories (via updates or via the installer), a significant fraction might well run into this same problem.

When I use -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient45 to disable the provider for this implementation, I of course see no log entries nor do any repositories fail to load.

I'm starting to get the feeling that either a) the server is ill-behaved or b) there is a problem in the httpclient implementation.  Perhaps some Keep-Alive header: is poor or not being respected by the implementation.

I saw something similar here where the server was blamed:

  https://support.sonatype.com/hc/en-us/articles/213465028-Understanding-The-target-server-failed-to-respond-in-Nexus-logs

Does anyone have any ideas?

Regards,
Ed






_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Andrey Loskutov
Some time ago I've also stumbled over it while meditating over maven build logs:
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=558976
 
I *believe* I haven't seen such errors before, and I *believe* this could be due infrastructure changes we had recently.
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Mittwoch, 04. März 2020 um 13:31 Uhr
Von: "Ed Merks" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: [platform-dev] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Hi,

I don't know how many of you have noticed things like this in the build logs:

 
12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute 12:25:45 INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond 12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute 12:25:45 INFO: Retrying request to {s}->https://download.eclipse.org:443

I'm a bit concerned about the cause of such exceptions.  I've debugged where this happens in my Oomph environment.  Specifically it happens in org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when parsing the response header finds nothing with the following stack leading to the logged problem:

org.apache.http.NoHttpResponseException.<init>(java.lang.String) line: 47   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 141   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 56   
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser<T>).parse() line: 259   
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() line: 163   
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157   
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 273   
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 125   
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 272   
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 186   
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 89   
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 110   
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) line: 185   
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, org.apache.http.protocol.HttpContext) line: 83   
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() line: 246   
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) line: 69   
org.eclipse.core.internal.jobs.Worker.run() line: 63   

There will be two additional retries, and if those fail too, the repository will fail to load (or the artifact will fail to download).   In my product catalog generator, I load a whole whack of repositories and this happens frequently enough that more often than not, one or more repositories fail to load.  This concerns me because with 2 million users loading repositories (via updates or via the installer), a significant fraction might well run into this same problem.

When I use -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient45 to disable the provider for this implementation, I of course see no log entries nor do any repositories fail to load.

I'm starting to get the feeling that either a) the server is ill-behaved or b) there is a problem in the httpclient implementation.  Perhaps some Keep-Alive header: is poor or not being respected by the implementation.

I saw something similar here where the server was blamed:

  https://support.sonatype.com/hc/en-us/articles/213465028-Understanding-The-target-server-failed-to-respond-in-Nexus-logs

Does anyone have any ideas?

Regards,
Ed

 

 

 

 

_______________________________________________ platform-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Ed Merks-2

Andrey,

Thanks for the response!

These are definitely in the platform's build logs, e.g., this one always has such entries:

https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/lastSuccessfulBuild/consoleFull

I too get the sense that this is a new/recent thing.  I thought maybe a new version of httpclient was to blame, but I have the same problem in an older environment with an older version of httpclient, and I definitely did not have this highly reproducible problem a few months ago when I was using that older environment regularly.

Regards,
Ed

On 04.03.2020 13:41, Andrey Loskutov wrote:
Some time ago I've also stumbled over it while meditating over maven build logs:
 
 
I *believe* I haven't seen such errors before, and I *believe* this could be due infrastructure changes we had recently.
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Mittwoch, 04. März 2020 um 13:31 Uhr
Von: "Ed Merks" [hidden email]
An: "Eclipse platform general developers list." [hidden email]
Betreff: [platform-dev] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Hi,

I don't know how many of you have noticed things like this in the build logs:

 
12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute 12:25:45 INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond 12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute 12:25:45 INFO: Retrying request to {s}->https://download.eclipse.org:443

I'm a bit concerned about the cause of such exceptions.  I've debugged where this happens in my Oomph environment.  Specifically it happens in org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when parsing the response header finds nothing with the following stack leading to the logged problem:

org.apache.http.NoHttpResponseException.<init>(java.lang.String) line: 47   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 141   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 56   
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser<T>).parse() line: 259   
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() line: 163   
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157   
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 273   
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 125   
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 272   
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 186   
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 89   
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 110   
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) line: 185   
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, org.apache.http.protocol.HttpContext) line: 83   
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() line: 246   
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) line: 69   
org.eclipse.core.internal.jobs.Worker.run() line: 63   

There will be two additional retries, and if those fail too, the repository will fail to load (or the artifact will fail to download).   In my product catalog generator, I load a whole whack of repositories and this happens frequently enough that more often than not, one or more repositories fail to load.  This concerns me because with 2 million users loading repositories (via updates or via the installer), a significant fraction might well run into this same problem.

When I use -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient45 to disable the provider for this implementation, I of course see no log entries nor do any repositories fail to load.

I'm starting to get the feeling that either a) the server is ill-behaved or b) there is a problem in the httpclient implementation.  Perhaps some Keep-Alive header: is poor or not being respected by the implementation.

I saw something similar here where the server was blamed:

  https://support.sonatype.com/hc/en-us/articles/213465028-Understanding-The-target-server-failed-to-respond-in-Nexus-logs

Does anyone have any ideas?

Regards,
Ed

 

 

 

 

_______________________________________________ platform-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Aleksandar Kurtakov
In reply to this post by Ed Merks-2


On Wed, Mar 4, 2020 at 2:32 PM Ed Merks <[hidden email]> wrote:

Hi,

I don't know how many of you have noticed things like this in the build logs:

12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute
12:25:45 INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
12:25:45 Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute
12:25:45 INFO: Retrying request to {s}->https://download.eclipse.org:443

I'm a bit concerned about the cause of such exceptions.  I've debugged where this happens in my Oomph environment.  Specifically it happens in org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when parsing the response header finds nothing with the following stack leading to the logged problem:

org.apache.http.NoHttpResponseException.<init>(java.lang.String) line: 47   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 141   
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) line: 56   
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser<T>).parse() line: 259   
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() line: 163   
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157   
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 273   
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, org.apache.http.HttpClientConnection, org.apache.http.protocol.HttpContext) line: 125   
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 272   
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 186   
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 89   
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, org.apache.http.client.methods.HttpRequestWrapper, org.apache.http.client.protocol.HttpClientContext, org.apache.http.client.methods.HttpExecutionAware) line: 110   
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) line: 185   
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, org.apache.http.protocol.HttpContext) line: 83   
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() line: 246   
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) line: 69   
org.eclipse.core.internal.jobs.Worker.run() line: 63   

There will be two additional retries, and if those fail too, the repository will fail to load (or the artifact will fail to download).   In my product catalog generator, I load a whole whack of repositories and this happens frequently enough that more often than not, one or more repositories fail to load.  This concerns me because with 2 million users loading repositories (via updates or via the installer), a significant fraction might well run into this same problem.

When I use -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient45 to disable the provider for this implementation, I of course see no log entries nor do any repositories fail to load.

I'm starting to get the feeling that either a) the server is ill-behaved or b) there is a problem in the httpclient implementation.  Perhaps some Keep-Alive header: is poor or not being respected by the implementation.

I saw something similar here where the server was blamed:

  https://support.sonatype.com/hc/en-us/articles/213465028-Understanding-The-target-server-failed-to-respond-in-Nexus-logs

Does anyone have any ideas?


Slightly off topic but keeping up with httpclient has proved to be a big timesync. It's probably about time to start working on https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html based filetransfer implementation and stop losing the time to keep up with yet another third party library.
 

Regards,
Ed





_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Ed Merks-2
This assumes that the problem really is httpclient's fault, which is
kind of questionable given how widely used that library is. I'd also be
concerned about all the problems such as proxy authentication and so on
that have been carefully ironed out over the years that would need to
start from scratch.   Also, perhaps we'd lose many features, such as a
connection pool to speed things up.   It's a big open question...

On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to be a
> big timesync. It's probably about time to start working on
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html 
> based filetransfer implementation and stop losing the time to keep up
> with yet another third party library.
_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Aleksandar Kurtakov


On Wed, Mar 4, 2020 at 2:55 PM Ed Merks <[hidden email]> wrote:
This assumes that the problem really is httpclient's fault, which is
kind of questionable given how widely used that library is. I'd also be
concerned about all the problems such as proxy authentication and so on
that have been carefully ironed out over the years that would need to
start from scratch.   Also, perhaps we'd lose many features, such as a
connection pool to speed things up.   It's a big open question...

In terms of lose of features my brief look up yielded nothing (e.g.  connection pool is "HttpClient.executor(Executors.newFixedThreadPool(NUMBER))" regarding proxy support I would be really surprised if the in JVM implementations support less things than apache httpclient.
This is meant to be food for thought as keeping up with all the third party dependencies is really a whole lot of work with people willing to do it becoming less and less. That's the reason I look for ways to reduce that work as I don't have high hopes people will jump in to do that work.
 

On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to be a
> big timesync. It's probably about time to start working on
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> based filetransfer implementation and stop losing the time to keep up
> with yet another third party library.
_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Aleksandar Kurtakov


On Wed, Mar 4, 2020 at 3:11 PM Aleksandar Kurtakov <[hidden email]> wrote:


On Wed, Mar 4, 2020 at 2:55 PM Ed Merks <[hidden email]> wrote:
This assumes that the problem really is httpclient's fault, which is
kind of questionable given how widely used that library is. I'd also be
concerned about all the problems such as proxy authentication and so on
that have been carefully ironed out over the years that would need to
start from scratch.   Also, perhaps we'd lose many features, such as a
connection pool to speed things up.   It's a big open question...

In terms of lose of features my brief look up yielded nothing (e.g.  connection pool is "HttpClient.executor(Executors.newFixedThreadPool(NUMBER))" regarding proxy support I would be really surprised if the in JVM implementations support less things than apache httpclient.
This is meant to be food for thought as keeping up with all the third party dependencies is really a whole lot of work with people willing to do it becoming less and less. That's the reason I look for ways to reduce that work as I don't have high hopes people will jump in to do that work.

Now I see that I forgot sharing the root cause of these thoughts https://downloads.apache.org/httpcomponents/httpclient/RELEASE_NOTES-5.0.x.txt .  Assuming this is major rewrite pending in ECF it might be good time to think of switching to the JVM classes.
 
 

On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to be a
> big timesync. It's probably about time to start working on
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> based filetransfer implementation and stop losing the time to keep up
> with yet another third party library.
_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


--
Alexander Kurtakov
Red Hat Eclipse Team


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Thomas Wolf
In reply to this post by Aleksandar Kurtakov

On 4 Mar 2020, at 14:11, Aleksandar Kurtakov <[hidden email]> wrote:

On Wed, Mar 4, 2020 at 2:55 PM Ed Merks <[hidden email]> wrote:
...
start from scratch.   Also, perhaps we'd lose many features, such as a
connection pool to speed things up.   It's a big open question...

In terms of lose of features my brief look up yielded nothing (e.g.  connection pool is
....
 

On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to be a
> big timesync. It's probably about time to start working on
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> based filetransfer implementation and stop losing the time to keep up
> with yet another third party library.

I think you might lose https connections over http proxies that require
basic authentication unless you set a particular system property. See
Java 11 HttpClient will behave the same in that respect.

Cheers,

  Thomas

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

Ed Merks-2

FYI,

I did some more debugging and I really feel this is a server problem.  I.e., I believe the server is dropping connections while the headers from those connections indicate the connection can be kept alive indefinitely.

I opened the following Bugzilla with the details if you're interested:

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

Regards,
Ed

On 04.03.2020 14:37, Thomas Wolf wrote:

On 4 Mar 2020, at 14:11, Aleksandar Kurtakov <[hidden email]> wrote:

On Wed, Mar 4, 2020 at 2:55 PM Ed Merks <[hidden email]> wrote:
...
start from scratch.   Also, perhaps we'd lose many features, such as a
connection pool to speed things up.   It's a big open question...

In terms of lose of features my brief look up yielded nothing (e.g.  connection pool is
....
 

On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to be a
> big timesync. It's probably about time to start working on
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> based filetransfer implementation and stop losing the time to keep up
> with yet another third party library.

I think you might lose https connections over http proxies that require
basic authentication unless you set a particular system property. See
Java 11 HttpClient will behave the same in that respect.

Cheers,

  Thomas

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev