You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Kalnichevski, Oleg" <ol...@bearingpoint.com> on 2003/01/16 16:53:02 UTC
[PATCH] Connection pooling logic does not take protocol into account
Mike, I'd appreciate if commented on the changes I have made
Oleg
-----Original Message-----
From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
Sent: Thursday, January 16, 2003 6:51 AM
To: Commons HttpClient Project
Subject: Re: protocol support
Well, here's a patch that changes the key for the connection pool from
host + ":" + port
to
host + ":" + port + "-" + protocol.getSocketFactory().toString()
It's a little ugly, but perhaps better than making all Implementors of
Protocol figure out a sensible value themselves.
Let me know if I missed something, Simon
----- Original Message -----
From: "Kalnichevski, Oleg" <ol...@bearingpoint.com>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Cc: <si...@fifthweb.net>
Sent: Tuesday, January 14, 2003 5:15 AM
Subject: RE: protocol support
Simon, the patch will be welcome, of course. Just let us know if have time
and interest for contributing it. We should also quickly check with Mike,
though, to make sure your efforts would not overlap with his
Cheers
Oleg
-----Original Message-----
From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
Sent: Friday, January 10, 2003 12:50 PM
To: Commons HttpClient Project
Subject: Re: protocol support
Not that it actually works for in the current codebase (for
MultiThreadedHttpConnectionManager, for multiple connections to the same
host, anyway), as I noted. I can submit a patch that adds the the Protocol
to the key used in the connection pool, if y'like.
----- Original Message -----
From: "Ortwin Glück" <or...@nose.ch>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Friday, January 10, 2003 9:30 PM
Subject: Re: protocol support
> You can register your own protocols via
> Protocol.registerProtocol(String, Protocol). However HttpClient is only
> meant to handle http and https. FTP, Gopher and others are not handled
> by HttpClient. The main use of registerProtocol method is to register
> custom SocketFactories. So you would mostly register protocols like
> 'https1', 'https2' for different client certificates with SSL.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.441 / Virus Database: 247 - Release Date: 9/01/2003
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: [PATCH] Connection pooling logic does not take protocol into
account
Posted by Michael Becke <be...@u.washington.edu>.
Sure. I'll work on it tonight.
Mike
Oleg Kalnichevski wrote:
> Makes sense to me. Do you mind leading the charge?
>
> Oleg
>
>
> On Thu, 2003-01-16 at 17:35, Michael Becke wrote:
>
>>Oleg, Simon,
>>
>>I think we may also want to take proxy settings into effect, as these
>>also change the connection. I think the HostConfiguration contains all
>>of the data needed to uniquely ID a connnection method.
>>
>>I would suggest something like the following:
>>
>>- change the storage of connection to be on a per HostConfiguration basis
>>- change HostConfiguration.equals() to add object comparison on the protocol
>>- remove generateKey() from Protocol and instead use Protocol.equals()
>>to test for protocol uniqueness
>>- change getConnectionsInUse(String) to
>>getConnectionsInUse(HostConfiguration)
>>- change the definition of maxConnectionsPerHost to be more descriptive
>>of how connections are managed
>>
>>
>>Mike
>>
>>Kalnichevski, Oleg wrote:
>>
>>>Mike, I'd appreciate if commented on the changes I have made
>>>
>>>Oleg
>>>
>>>
>>>-----Original Message-----
>>>From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
>>>Sent: Thursday, January 16, 2003 6:51 AM
>>>To: Commons HttpClient Project
>>>Subject: Re: protocol support
>>>
>>>
>>>Well, here's a patch that changes the key for the connection pool from
>>>
>>> host + ":" + port
>>>
>>>to
>>>
>>> host + ":" + port + "-" + protocol.getSocketFactory().toString()
>>>
>>>It's a little ugly, but perhaps better than making all Implementors of
>>>Protocol figure out a sensible value themselves.
>>>
>>>Let me know if I missed something, Simon
>>>
>>>
>>>
>>>----- Original Message -----
>>>From: "Kalnichevski, Oleg" <ol...@bearingpoint.com>
>>>To: "Commons HttpClient Project" <co...@jakarta.apache.org>
>>>Cc: <si...@fifthweb.net>
>>>Sent: Tuesday, January 14, 2003 5:15 AM
>>>Subject: RE: protocol support
>>>
>>>
>>>Simon, the patch will be welcome, of course. Just let us know if have time
>>>and interest for contributing it. We should also quickly check with Mike,
>>>though, to make sure your efforts would not overlap with his
>>>Cheers
>>>Oleg
>>>
>>>-----Original Message-----
>>>From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
>>>Sent: Friday, January 10, 2003 12:50 PM
>>>To: Commons HttpClient Project
>>>Subject: Re: protocol support
>>>
>>>
>>>Not that it actually works for in the current codebase (for
>>>MultiThreadedHttpConnectionManager, for multiple connections to the same
>>>host, anyway), as I noted. I can submit a patch that adds the the Protocol
>>>to the key used in the connection pool, if y'like.
>>>
>>>
>>>----- Original Message -----
>>>From: "Ortwin Glück" <or...@nose.ch>
>>>To: "Commons HttpClient Project" <co...@jakarta.apache.org>
>>>Sent: Friday, January 10, 2003 9:30 PM
>>>Subject: Re: protocol support
>>>
>>>
>>>
>>>
>>>>You can register your own protocols via
>>>>Protocol.registerProtocol(String, Protocol). However HttpClient is only
>>>>meant to handle http and https. FTP, Gopher and others are not handled
>>>>by HttpClient. The main use of registerProtocol method is to register
>>>>custom SocketFactories. So you would mostly register protocols like
>>>>'https1', 'https2' for different client certificates with SSL.
>>>
>>>
>>>
>>>
>>>---
>>>Outgoing mail is certified Virus Free.
>>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>>Version: 6.0.441 / Virus Database: 247 - Release Date: 9/01/2003
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Connection pooling logic does not take protocol into
account
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
Makes sense to me. Do you mind leading the charge?
Oleg
On Thu, 2003-01-16 at 17:35, Michael Becke wrote:
> Oleg, Simon,
>
> I think we may also want to take proxy settings into effect, as these
> also change the connection. I think the HostConfiguration contains all
> of the data needed to uniquely ID a connnection method.
>
> I would suggest something like the following:
>
> - change the storage of connection to be on a per HostConfiguration basis
> - change HostConfiguration.equals() to add object comparison on the protocol
> - remove generateKey() from Protocol and instead use Protocol.equals()
> to test for protocol uniqueness
> - change getConnectionsInUse(String) to
> getConnectionsInUse(HostConfiguration)
> - change the definition of maxConnectionsPerHost to be more descriptive
> of how connections are managed
>
>
> Mike
>
> Kalnichevski, Oleg wrote:
> > Mike, I'd appreciate if commented on the changes I have made
> >
> > Oleg
> >
> >
> > -----Original Message-----
> > From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
> > Sent: Thursday, January 16, 2003 6:51 AM
> > To: Commons HttpClient Project
> > Subject: Re: protocol support
> >
> >
> > Well, here's a patch that changes the key for the connection pool from
> >
> > host + ":" + port
> >
> > to
> >
> > host + ":" + port + "-" + protocol.getSocketFactory().toString()
> >
> > It's a little ugly, but perhaps better than making all Implementors of
> > Protocol figure out a sensible value themselves.
> >
> > Let me know if I missed something, Simon
> >
> >
> >
> > ----- Original Message -----
> > From: "Kalnichevski, Oleg" <ol...@bearingpoint.com>
> > To: "Commons HttpClient Project" <co...@jakarta.apache.org>
> > Cc: <si...@fifthweb.net>
> > Sent: Tuesday, January 14, 2003 5:15 AM
> > Subject: RE: protocol support
> >
> >
> > Simon, the patch will be welcome, of course. Just let us know if have time
> > and interest for contributing it. We should also quickly check with Mike,
> > though, to make sure your efforts would not overlap with his
> > Cheers
> > Oleg
> >
> > -----Original Message-----
> > From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
> > Sent: Friday, January 10, 2003 12:50 PM
> > To: Commons HttpClient Project
> > Subject: Re: protocol support
> >
> >
> > Not that it actually works for in the current codebase (for
> > MultiThreadedHttpConnectionManager, for multiple connections to the same
> > host, anyway), as I noted. I can submit a patch that adds the the Protocol
> > to the key used in the connection pool, if y'like.
> >
> >
> > ----- Original Message -----
> > From: "Ortwin Glück" <or...@nose.ch>
> > To: "Commons HttpClient Project" <co...@jakarta.apache.org>
> > Sent: Friday, January 10, 2003 9:30 PM
> > Subject: Re: protocol support
> >
> >
> >
> >>You can register your own protocols via
> >>Protocol.registerProtocol(String, Protocol). However HttpClient is only
> >>meant to handle http and https. FTP, Gopher and others are not handled
> >>by HttpClient. The main use of registerProtocol method is to register
> >>custom SocketFactories. So you would mostly register protocols like
> >>'https1', 'https2' for different client certificates with SSL.
> >
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.441 / Virus Database: 247 - Release Date: 9/01/2003
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Oleg Kalnichevski <o....@dplanet.ch>
Re: [PATCH] Connection pooling logic does not take protocol into
account
Posted by Simon Roberts <si...@fifthweb.net>.
Sure, that sounds like a more sensible way than adding more hair to the the
key for the connection pool.
----- Original Message -----
From: "Michael Becke" <be...@u.washington.edu>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Friday, January 17, 2003 5:35 AM
Subject: Re: [PATCH] Connection pooling logic does not take protocol into
account
> Oleg, Simon,
>
> I think we may also want to take proxy settings into effect, as these
> also change the connection. I think the HostConfiguration contains all
> of the data needed to uniquely ID a connnection method.
>
> I would suggest something like the following:
>
> - change the storage of connection to be on a per HostConfiguration basis
> - change HostConfiguration.equals() to add object comparison on the
protocol
> - remove generateKey() from Protocol and instead use Protocol.equals()
> to test for protocol uniqueness
> - change getConnectionsInUse(String) to
> getConnectionsInUse(HostConfiguration)
> - change the definition of maxConnectionsPerHost to be more descriptive
> of how connections are managed
Re: [PATCH] Connection pooling logic does not take protocol into
account
Posted by Michael Becke <be...@u.washington.edu>.
Oleg, Simon,
I think we may also want to take proxy settings into effect, as these
also change the connection. I think the HostConfiguration contains all
of the data needed to uniquely ID a connnection method.
I would suggest something like the following:
- change the storage of connection to be on a per HostConfiguration basis
- change HostConfiguration.equals() to add object comparison on the protocol
- remove generateKey() from Protocol and instead use Protocol.equals()
to test for protocol uniqueness
- change getConnectionsInUse(String) to
getConnectionsInUse(HostConfiguration)
- change the definition of maxConnectionsPerHost to be more descriptive
of how connections are managed
Mike
Kalnichevski, Oleg wrote:
> Mike, I'd appreciate if commented on the changes I have made
>
> Oleg
>
>
> -----Original Message-----
> From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
> Sent: Thursday, January 16, 2003 6:51 AM
> To: Commons HttpClient Project
> Subject: Re: protocol support
>
>
> Well, here's a patch that changes the key for the connection pool from
>
> host + ":" + port
>
> to
>
> host + ":" + port + "-" + protocol.getSocketFactory().toString()
>
> It's a little ugly, but perhaps better than making all Implementors of
> Protocol figure out a sensible value themselves.
>
> Let me know if I missed something, Simon
>
>
>
> ----- Original Message -----
> From: "Kalnichevski, Oleg" <ol...@bearingpoint.com>
> To: "Commons HttpClient Project" <co...@jakarta.apache.org>
> Cc: <si...@fifthweb.net>
> Sent: Tuesday, January 14, 2003 5:15 AM
> Subject: RE: protocol support
>
>
> Simon, the patch will be welcome, of course. Just let us know if have time
> and interest for contributing it. We should also quickly check with Mike,
> though, to make sure your efforts would not overlap with his
> Cheers
> Oleg
>
> -----Original Message-----
> From: Simon Roberts [mailto:simon.roberts@fifthweb.net]
> Sent: Friday, January 10, 2003 12:50 PM
> To: Commons HttpClient Project
> Subject: Re: protocol support
>
>
> Not that it actually works for in the current codebase (for
> MultiThreadedHttpConnectionManager, for multiple connections to the same
> host, anyway), as I noted. I can submit a patch that adds the the Protocol
> to the key used in the connection pool, if y'like.
>
>
> ----- Original Message -----
> From: "Ortwin Glück" <or...@nose.ch>
> To: "Commons HttpClient Project" <co...@jakarta.apache.org>
> Sent: Friday, January 10, 2003 9:30 PM
> Subject: Re: protocol support
>
>
>
>>You can register your own protocols via
>>Protocol.registerProtocol(String, Protocol). However HttpClient is only
>>meant to handle http and https. FTP, Gopher and others are not handled
>>by HttpClient. The main use of registerProtocol method is to register
>>custom SocketFactories. So you would mostly register protocols like
>>'https1', 'https2' for different client certificates with SSL.
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.441 / Virus Database: 247 - Release Date: 9/01/2003
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>