Whew! Thanks for the heads-up about the problem, and confirmation
that the fix works, Paul.
Sam
On Tue, Jul 1, 2008 at 7:16 PM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> That did it. I'm running svn head on one production server and seeing very
> good behavior.
>
> On Jun 30, 2008, at 6:53 PM,
That did it. I'm running svn head on one production server and seeing
very good behavior.
On Jun 30, 2008, at 6:53 PM, Sam Berlin wrote:
Hi Paul,
I think I've fixed this one -- the problem was using deleteEntry
instead of dropEntry. The former required the entry to be considered
'free', bu
Hi Paul,
I think I've fixed this one -- the problem was using deleteEntry
instead of dropEntry. The former required the entry to be considered
'free', but the entry had just been allocated and was definitely not
'free'. I'm pretty certain this will indirectly fix the
connection/memory leak -- a
I can take a look later tonight -- feel free to do it sooner if you'd
like to rule it out as a cause of the leak & debug that.
On Mon, Jun 30, 2008 at 2:56 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-06-30 at 14:54 -0400, Sam Berlin wrote:
>> Yeah, that makes sense. Dunno what
On Mon, 2008-06-30 at 14:54 -0400, Sam Berlin wrote:
> Yeah, that makes sense. Dunno what was going through my head at the
> time, but for some reason I thought it made sense to calculate the
> time when the headers are read. It definitely simplifies the code to
> do it just when the connection i
Yeah, that makes sense. Dunno what was going through my head at the
time, but for some reason I thought it made sense to calculate the
time when the headers are read. It definitely simplifies the code to
do it just when the connection is released.
Sam
On Mon, Jun 30, 2008 at 2:51 PM, Oleg Kalni
On Mon, 2008-06-30 at 10:43 -0400, Sam Berlin wrote:
> Yikes, that's no good. Did you test this using the first revision of
> the fix or the second (changed to use 'setIdleDuration' in
> ManagedClientConnection)?
>
> Think it'd be possible to isolate the problem to a unit test?
>
> Sam
>
Sam,
The tests below were using the latest trunk code (r672641)
I reverted back to r670018, where things are stable.
I can try and see if I can reproduce it, but it may take some time.
If anyone wants to try this it should be a simple matter.
Configure an apache server to return headers like thi
Yikes, that's no good. Did you test this using the first revision of
the fix or the second (changed to use 'setIdleDuration' in
ManagedClientConnection)?
Think it'd be possible to isolate the problem to a unit test?
Sam
On Mon, Jun 30, 2008 at 10:33 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
>
I tested this code using production traffic and the results are not so
good. Ended up with a connection/memory leak. The jmap histogram of
a server in this bad state is attached.
Also, I had some issues with one host, it used a keepalive with a
timeout=1. It appears that the route pool
FYI, the fix is in there now (along with a bunch of new tests), and a
new 'closeExpiredConnections' method that can be used the same way
closeIdleConnections works if you want to bulk-close all expired
connections at any given moment.
Sam
On Wed, Jun 25, 2008 at 5:52 PM, Oleg Kalnichevski <[EMAIL
On Wed, 2008-06-25 at 17:42 -0400, Sam Berlin wrote:
> Done @ https://issues.apache.org/jira/browse/HTTPCLIENT-781 . I can
> take a look at this in the coming days -- do you think an
> implementation that just closes the prior connection & makes a new one
> on a subsequent request is OK, or does H
Done @ https://issues.apache.org/jira/browse/HTTPCLIENT-781 . I can
take a look at this in the coming days -- do you think an
implementation that just closes the prior connection & makes a new one
on a subsequent request is OK, or does HttpClient need to close the
connection immediately once the t
On Wed, 2008-06-25 at 17:14 -0400, Sam Berlin wrote:
> Hi Folks,
>
> We just stumbled across an issue with persistent connections where the
> server is sending a Connection: Keep-Alive header, but also a
> Keep-Alive header with a timeout=## (and a max=##). HttpClient's
> connection management se
Hi Folks,
We just stumbled across an issue with persistent connections where the
server is sending a Connection: Keep-Alive header, but also a
Keep-Alive header with a timeout=## (and a max=##). HttpClient's
connection management sees that the connection can be kept alive, so
pools it for potenti
15 matches
Mail list logo
