You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/08/09 18:39:51 UTC
[Fwd: RE: MultithreadedConnectionManager pooling strategy]
Folks,
The message I am forwarding was sent to the HttpClient user list a while
ago. I think the changes proposed by Balazs are very reasonable.
Unfortunately Balazs never submitted the patch and did not return emails
I had sent him off-list. Nonetheless, I think we should consider
changing MultithreadedConnectionManager's behavior as proposed by Balazs
and include those changes into 3.1-beta1
Mike, what do you think?
Oleg
-------- Forwarded Message --------
From: SZÜCS Balazs <Ba...@wave-solutions.com>
Reply-To: HttpClient User Discussion
<ht...@jakarta.apache.org>
To: 'HttpClient User Discussion' <ht...@jakarta.apache.org>
Subject: RE: MultithreadedConnectionManager pooling strategy
Date: Mon, 15 May 2006 15:26:08 +0200
Hello,
I made two changes to the HttpClient code:
1) in the class ConnectionPool in the method getFreeConnection( ... ) I
changed freeConnections.removeFirst() to freeConnections.removeLast(). Now
the container for free connections behaves as a stack rather than a queue.
2) additionally I changed the IdleConnectionTimeoutThread, in the run()
method I added connectionManager.deleteClosedConnections() so that the pool
size is maintained correctly.
What do you think?
Balazs
-----Original Message-----
From: Oleg Kalnichevski <ol...@apache.org>@DSI
Sent: Donnerstag, 04. Mai 2006 18:07
To: HttpClient User Discussion
Subject: Re: MultithreadedConnectionManager pooling strategy
On Thu, 2006-05-04 at 18:00 +0200, SZÜCS Balazs wrote:
> Hello,
>
> I'm using HttpClient 3.0-rc4, and I have a question about the
connection
> pooling strategy of MultithreadedConnectionManager. The reason for
that is
> that I use an IdleConnectionTimeoutThread (runs every 60 secs,
using a
> timeout of 60 secs) configured with a
MultithreadedConnectionManager, and
> idle connections don't seem to get closed by the
> IdleConnectionTimeoutThread. However, on a long time span
(overnight) the
> pool size decreases, but I would expect a quicker reaction, when
my
> application is not unter heavy load.
>
> I've taken a look at the source of MultithreadedConnectionManager,
and I
> realized, that free connections are stored in a linked list. On
demand the
> next free connection is taken from the BEGINNING of the list,
while after
> usage the connection is put back to the END of the list. This
seems to me a
> round robin behavior, and it might prevent connections reaching
the
> predefined age for being recognized as idle. If there is some
load, each
> free connection will be used, instead of just using a few of them,
and
> letting the rest age.
>
> Does that make any sense?
>
Balazs,
Yes, it does. Please file a bug report in Bugzilla. Feel free to
provide
a patch for the problem. We love patches ;-)
Oleg
> Thank you!
>
> Balazs
---------------------------------------------------------------------
To unsubscribe, e-mail:
httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
httpclient-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Fwd: RE: MultithreadedConnectionManager pooling strategy]
Posted by Ortwin Glück <od...@odi.ch>.
Yep, seems to make sense.
Odi
Oleg Kalnichevski wrote:
> Folks,
>
> The message I am forwarding was sent to the HttpClient user list a while
> ago. I think the changes proposed by Balazs are very reasonable.
> Unfortunately Balazs never submitted the patch and did not return emails
> I had sent him off-list. Nonetheless, I think we should consider
> changing MultithreadedConnectionManager's behavior as proposed by Balazs
> and include those changes into 3.1-beta1
>
> Mike, what do you think?
>
> Oleg
>
> -------- Forwarded Message --------
> From: SZÜCS Balazs <Ba...@wave-solutions.com>
> Reply-To: HttpClient User Discussion
> <ht...@jakarta.apache.org>
> To: 'HttpClient User Discussion' <ht...@jakarta.apache.org>
> Subject: RE: MultithreadedConnectionManager pooling strategy
> Date: Mon, 15 May 2006 15:26:08 +0200
>
> Hello,
>
> I made two changes to the HttpClient code:
>
> 1) in the class ConnectionPool in the method getFreeConnection( ... ) I
> changed freeConnections.removeFirst() to freeConnections.removeLast(). Now
> the container for free connections behaves as a stack rather than a queue.
>
> 2) additionally I changed the IdleConnectionTimeoutThread, in the run()
> method I added connectionManager.deleteClosedConnections() so that the pool
> size is maintained correctly.
>
> What do you think?
> Balazs
>
> -----Original Message-----
> From: Oleg Kalnichevski <ol...@apache.org>@DSI
> Sent: Donnerstag, 04. Mai 2006 18:07
> To: HttpClient User Discussion
> Subject: Re: MultithreadedConnectionManager pooling strategy
>
> On Thu, 2006-05-04 at 18:00 +0200, SZÜCS Balazs wrote:
> > Hello,
> >
> > I'm using HttpClient 3.0-rc4, and I have a question about the
> connection
> > pooling strategy of MultithreadedConnectionManager. The reason for
> that is
> > that I use an IdleConnectionTimeoutThread (runs every 60 secs,
> using a
> > timeout of 60 secs) configured with a
> MultithreadedConnectionManager, and
> > idle connections don't seem to get closed by the
> > IdleConnectionTimeoutThread. However, on a long time span
> (overnight) the
> > pool size decreases, but I would expect a quicker reaction, when
> my
> > application is not unter heavy load.
> >
> > I've taken a look at the source of MultithreadedConnectionManager,
> and I
> > realized, that free connections are stored in a linked list. On
> demand the
> > next free connection is taken from the BEGINNING of the list,
> while after
> > usage the connection is put back to the END of the list. This
> seems to me a
> > round robin behavior, and it might prevent connections reaching
> the
> > predefined age for being recognized as idle. If there is some
> load, each
> > free connection will be used, instead of just using a few of them,
> and
> > letting the rest age.
> >
> > Does that make any sense?
> >
>
> Balazs,
>
> Yes, it does. Please file a bug report in Bugzilla. Feel free to
> provide
> a patch for the problem. We love patches ;-)
>
> Oleg
>
> > Thank you!
> >
> > Balazs
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Fwd: RE: MultithreadedConnectionManager pooling strategy]
Posted by Michael Becke <mb...@gmail.com>.
Agreed. They make sense. The second one will be a little messy since
it requires adding deleteClosedConnections() to HttpConnectionManager.
Instead we could just make IdleConnectionTimeoutThread more easily
customizable. I'll create an issue in Jira and attach a possible
patch.
Mike
On 8/9/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> Folks,
>
> The message I am forwarding was sent to the HttpClient user list a while
> ago. I think the changes proposed by Balazs are very reasonable.
> Unfortunately Balazs never submitted the patch and did not return emails
> I had sent him off-list. Nonetheless, I think we should consider
> changing MultithreadedConnectionManager's behavior as proposed by Balazs
> and include those changes into 3.1-beta1
>
> Mike, what do you think?
>
> Oleg
>
> -------- Forwarded Message --------
> From: SZÜCS Balazs <Ba...@wave-solutions.com>
> Reply-To: HttpClient User Discussion
> <ht...@jakarta.apache.org>
> To: 'HttpClient User Discussion' <ht...@jakarta.apache.org>
> Subject: RE: MultithreadedConnectionManager pooling strategy
> Date: Mon, 15 May 2006 15:26:08 +0200
>
> Hello,
>
> I made two changes to the HttpClient code:
>
> 1) in the class ConnectionPool in the method getFreeConnection( ... ) I
> changed freeConnections.removeFirst() to freeConnections.removeLast(). Now
> the container for free connections behaves as a stack rather than a queue.
>
> 2) additionally I changed the IdleConnectionTimeoutThread, in the run()
> method I added connectionManager.deleteClosedConnections() so that the pool
> size is maintained correctly.
>
> What do you think?
> Balazs
>
> -----Original Message-----
> From: Oleg Kalnichevski <ol...@apache.org>@DSI
> Sent: Donnerstag, 04. Mai 2006 18:07
> To: HttpClient User Discussion
> Subject: Re: MultithreadedConnectionManager pooling strategy
>
> On Thu, 2006-05-04 at 18:00 +0200, SZÜCS Balazs wrote:
> > Hello,
> >
> > I'm using HttpClient 3.0-rc4, and I have a question about the
> connection
> > pooling strategy of MultithreadedConnectionManager. The reason for
> that is
> > that I use an IdleConnectionTimeoutThread (runs every 60 secs,
> using a
> > timeout of 60 secs) configured with a
> MultithreadedConnectionManager, and
> > idle connections don't seem to get closed by the
> > IdleConnectionTimeoutThread. However, on a long time span
> (overnight) the
> > pool size decreases, but I would expect a quicker reaction, when
> my
> > application is not unter heavy load.
> >
> > I've taken a look at the source of MultithreadedConnectionManager,
> and I
> > realized, that free connections are stored in a linked list. On
> demand the
> > next free connection is taken from the BEGINNING of the list,
> while after
> > usage the connection is put back to the END of the list. This
> seems to me a
> > round robin behavior, and it might prevent connections reaching
> the
> > predefined age for being recognized as idle. If there is some
> load, each
> > free connection will be used, instead of just using a few of them,
> and
> > letting the rest age.
> >
> > Does that make any sense?
> >
>
> Balazs,
>
> Yes, it does. Please file a bug report in Bugzilla. Feel free to
> provide
> a patch for the problem. We love patches ;-)
>
> Oleg
>
> > Thank you!
> >
> > Balazs
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org