Hi Oleg,
Thanks for that. I have now implemented my own MethodRetryHandler and
got rid of my custom loop / retry.
Cleaner log files for my application as well.
John
Kalnichevski, Oleg wrote:
John,
Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects socket
One small thing though. Why is setMethodRetryHandler() defined in
HttpMethodBase class instead of the HttpMethod interface ?
Jesus M. Salvo Jr. wrote:
Hi Oleg,
Thanks for that. I have now implemented my own MethodRetryHandler and
got rid of my custom loop / retry.
Cleaner log files for my
John
No reason other than HttpMethod HttpMethodBase being horrible
monstrosities badly in need of a compete redesign
Oleg
On Fri, 2004-05-14 at 09:02, Jesus M. Salvo Jr. wrote:
One small thing though. Why is setMethodRetryHandler() defined in
HttpMethodBase class instead of the HttpMethod
Some clarifications below.
Jesus M. Salvo Jr. wrote:
What I am seeing with ethereal is that, after 30 seconds of no
activity ( no TCP ACKs whatever on the socket ), the web server sends
a a TLS alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the
Jesus M. Salvo Jr. wrote:
Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?
What I have done now is, if I get a
John,
Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects
socket read operations. I thought it had nothing to do with SSL inactivity timeout.
But it looks like it might.
There's another way to deal with recoverable exceptions. You can provide a custom
