On Tue, Feb 15, 2011 at 3:06 PM, Oleg Kalnichevski ol...@apache.org wrote:
Well, I finally spotted an obvious problem with your code, which I
should have found earlier: HttpRequest objects are NOT thread-safe. They
may not be used by multiple threads.
Oleg
Hi Oleg,
By HttpRequest you mean
On 16 February 2011 10:41, Maxim Veksler ma...@vekslers.org wrote:
On Tue, Feb 15, 2011 at 3:06 PM, Oleg Kalnichevski ol...@apache.org wrote:
Well, I finally spotted an obvious problem with your code, which I
should have found earlier: HttpRequest objects are NOT thread-safe. They
may not be
On Wed, Feb 16, 2011 at 12:48 PM, sebb seb...@gmail.com wrote:
On 16 February 2011 10:41, Maxim Veksler ma...@vekslers.org wrote:
On Tue, Feb 15, 2011 at 3:06 PM, Oleg Kalnichevski ol...@apache.org wrote:
Well, I finally spotted an obvious problem with your code, which I
should have found
On Wed, 2011-02-16 at 14:47 +0200, Maxim Veksler wrote:
...
I've implemented the suggested changes. Please find them at the
revision
https://gist.github.com/829061/8a173df84ce47b288f6b34f675fc708fcf649535
This has improved the execution, now calling httpGet.abort(); does not
affect the
On Wed, Feb 16, 2011 at 3:14 PM, Oleg Kalnichevski ol...@apache.org wrote:
Once aborted a request cannot be executed again. Create a new HttpGet
instance for each request execution. They are cheap.
The problem is that HttpClient does not check whether or not a request
has been aborted prior
On Wed, 2011-02-16 at 16:31 +0200, Maxim Veksler wrote:
On Wed, Feb 16, 2011 at 3:14 PM, Oleg Kalnichevski ol...@apache.org wrote:
Once aborted a request cannot be executed again. Create a new HttpGet
instance for each request execution. They are cheap.
The problem is that HttpClient
Hello everyone,
I'm doing a small stress run from my Workstation to my Laptop.
The code is attached below.
This code emulates a situation where the connection pool runs out of
connections. I'm seeking to catch this situation and act properly.
My problem is that after a connection is being
On Tue, 2011-02-15 at 11:38 +0200, Maxim Veksler wrote:
Hello everyone,
I'm doing a small stress run from my Workstation to my Laptop.
The code is attached below.
This code emulates a situation where the connection pool runs out of
connections. I'm seeking to catch this situation and act
On Tue, Feb 15, 2011 at 2:03 PM, Oleg Kalnichevski ol...@apache.org wrote:
On Tue, 2011-02-15 at 11:38 +0200, Maxim Veksler wrote:
Hello everyone,
I'm doing a small stress run from my Workstation to my Laptop.
The code is attached below.
This code emulates a situation where the connection
HTTP_PARAMS.setParameter(
CoreConnectionPNames.SO_TIMEOUT, 200);
200 ms = 0.2 seconds. If youre making calls over the internet, you might
want to try a timeout of 15000ms (15 seconds).
I sometimes set it to 6ms b/c the internet can lag at times.
I would just set your timeout to 15000ms
Thanks for your response.
The test runs for ~25seconds and only then starts to fail.
Once it fails I eclipse trace it, by going step by step over the code
and the failure reproduces on each attempt.
Should the ThreadSafeClientConnManager attempt the reconnect or do I
need to do manual
On Tue, Feb 15, 2011 at 2:44 PM, Ryan Smith ryan.justin.sm...@gmail.com wrote:
ms = 0.2 seconds. If youre making calls over the internet, you might
want to try a timeout of 15000ms (15 seconds).
I sometimes set it to 6ms b/c the internet can lag at times.
I would just set your timeout to
On Tue, 2011-02-15 at 14:53 +0200, Maxim Veksler wrote:
On Tue, Feb 15, 2011 at 2:44 PM, Ryan Smith ryan.justin.sm...@gmail.com
wrote:
ms = 0.2 seconds. If youre making calls over the internet, you might
want to try a timeout of 15000ms (15 seconds).
I sometimes set it to 6ms b/c the
13 matches
Mail list logo
