You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Dobri Kitipov <kd...@googlemail.com> on 2009/03/26 20:51:13 UTC
Reuse of HttpClient and HttpState proposal
Hi all,
I am opening a new mail thread related to the following one "HTTP connection
leak and other related issues" [1].
Since this became really long and hairy discussion I decided not to post
there this mail.
The use case
I want to point out a concrete use case I have. I want to reuse a HttpClient
among different instances of a clients which are executed in different
threads. Every client can make several invocations. The clients can call
different Web Services (WSs) deployed at different hosts/servers. As a
consequence every client may need to provide different authentication
Credentials and may need to support transport sessions using Cookies.
Both Credentials and Cookies are part of the HttpState. As a result the
HttpState associated with the HttpClient that is reused cannot be reused
that easily in the scenario described in the above lines. Credentials are
associated with a given host, port, realm and authentication schema (defines
the AuthScope object used as a key for the credentials Map part of the
HttpState).
Following is an excerpt from the AbstractHTTPSender#setAuthenticationInfo:
creds = new UsernamePasswordCredentials(username, password);
agent.getState().setCredentials(new AuthScope(host, port, realm), creds);
Credentials are kept into a Map and could be indentified uniquely from
client to client (thread to thread), but this Map is exposed to all clients
which reuse the HttpClient which is not a good idea.
The situation with the other member of the HttpState (i.e. Cookies) is
similar. When we have to *different* instances of a client (configured to
use cookies options.setManageSession(true)) calling one and the same WS's
operation then the effect is that both are sharing one JSESSIONID.
The proposal
The proposal is based on my question posted at
httpclient-users@hc.apache.org [2]
The idea is to provide the capability to specify/associate a separate
HttpState with every client and still reuse one and the same HttpClient.
What you just need is to pass it as a parameter to the
HttpClient#executeMethod.
I decided that the HttpState should be kept into the ServiceContext. I did
all changes needed in Axis2 kernel (in fact they are really few) and added
the possibility to use a separate HttpState and invoke
HttpClient#executeMethod passing it as a parameter. The changes keep the
kernel backward compatible. I did and several tests and it looks good.
Please, give me your comments. Do you like this extension? If so I can
provide you with the changes and finally we can agree on committing them
into the kernel.
Thank you,
Dobri
[1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg45787.html
[2] http://www.mail-archive.com/httpclient-users@hc.apache.org/msg01944.html
Re: Reuse of HttpClient and HttpState proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Mar 27, 2009 at 1:21 AM, Dobri Kitipov <kdobrik.axis2@googlemail.com
> wrote:
> Hi all,
> I am opening a new mail thread related to the following one "HTTP
> connection
> leak and other related issues" [1].
> Since this became really long and hairy discussion I decided not to post
> there this mail.
>
> The use case
> I want to point out a concrete use case I have. I want to reuse a
> HttpClient
> among different instances of a clients which are executed in different
> threads. Every client can make several invocations. The clients can call
> different Web Services (WSs) deployed at different hosts/servers. As a
> consequence every client may need to provide different authentication
> Credentials and may need to support transport sessions using Cookies.
>
> Both Credentials and Cookies are part of the HttpState. As a result the
> HttpState associated with the HttpClient that is reused cannot be reused
> that easily in the scenario described in the above lines. Credentials are
> associated with a given host, port, realm and authentication schema
> (defines
> the AuthScope object used as a key for the credentials Map part of the
> HttpState).
>
> Following is an excerpt from the AbstractHTTPSender#setAuthenticationInfo:
>
> creds = new UsernamePasswordCredentials(username, password);
> agent.getState().setCredentials(new AuthScope(host, port, realm), creds);
>
> Credentials are kept into a Map and could be indentified uniquely from
> client to client (thread to thread), but this Map is exposed to all clients
> which reuse the HttpClient which is not a good idea.
>
> The situation with the other member of the HttpState (i.e. Cookies) is
> similar. When we have to *different* instances of a client (configured to
> use cookies options.setManageSession(true)) calling one and the same WS's
> operation then the effect is that both are sharing one JSESSIONID.
>
> The proposal
> The proposal is based on my question posted at
> httpclient-users@hc.apache.org [2]
> The idea is to provide the capability to specify/associate a separate
> HttpState with every client and still reuse one and the same HttpClient.
> What you just need is to pass it as a parameter to the
> HttpClient#executeMethod.
> I decided that the HttpState should be kept into the ServiceContext. I did
> all changes needed in Axis2 kernel (in fact they are really few) and added
> the possibility to use a separate HttpState and invoke
> HttpClient#executeMethod passing it as a parameter. The changes keep the
> kernel backward compatible. I did and several tests and it looks good.
>
> Please, give me your comments. Do you like this extension? If so I can
> provide you with the changes and finally we can agree on committing them
> into the kernel.
If I understand correctly you need to use the
public int executeMethod(org.apache.commons.httpclient.HostConfiguration
hostConfiguration, org.apache.commons.httpclient.HttpMethod httpMethod,
org.apache.commons.httpclient.HttpState httpState)
instead of two parameter method if the http state is stored at
serviceContext.
I think you have a valid use case there which can not provide with current
configurations.
Please create a jira and attach the patch.
thanks,
Amila.
>
> Thank you,
> Dobri
>
> [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg45787.html
> [2]
> http://www.mail-archive.com/httpclient-users@hc.apache.org/msg01944.html
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Reuse of HttpClient and HttpState proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Mar 27, 2009 at 1:21 AM, Dobri Kitipov <kdobrik.axis2@googlemail.com
> wrote:
> Hi all,
> I am opening a new mail thread related to the following one "HTTP
> connection
> leak and other related issues" [1].
> Since this became really long and hairy discussion I decided not to post
> there this mail.
>
> The use case
> I want to point out a concrete use case I have. I want to reuse a
> HttpClient
> among different instances of a clients which are executed in different
> threads. Every client can make several invocations. The clients can call
> different Web Services (WSs) deployed at different hosts/servers. As a
> consequence every client may need to provide different authentication
> Credentials and may need to support transport sessions using Cookies.
>
> Both Credentials and Cookies are part of the HttpState. As a result the
> HttpState associated with the HttpClient that is reused cannot be reused
> that easily in the scenario described in the above lines. Credentials are
> associated with a given host, port, realm and authentication schema
> (defines
> the AuthScope object used as a key for the credentials Map part of the
> HttpState).
>
> Following is an excerpt from the AbstractHTTPSender#setAuthenticationInfo:
>
> creds = new UsernamePasswordCredentials(username, password);
> agent.getState().setCredentials(new AuthScope(host, port, realm), creds);
>
> Credentials are kept into a Map and could be indentified uniquely from
> client to client (thread to thread), but this Map is exposed to all clients
> which reuse the HttpClient which is not a good idea.
>
> The situation with the other member of the HttpState (i.e. Cookies) is
> similar. When we have to *different* instances of a client (configured to
> use cookies options.setManageSession(true)) calling one and the same WS's
> operation then the effect is that both are sharing one JSESSIONID.
>
> The proposal
> The proposal is based on my question posted at
> httpclient-users@hc.apache.org [2]
> The idea is to provide the capability to specify/associate a separate
> HttpState with every client and still reuse one and the same HttpClient.
> What you just need is to pass it as a parameter to the
> HttpClient#executeMethod.
> I decided that the HttpState should be kept into the ServiceContext. I did
> all changes needed in Axis2 kernel (in fact they are really few) and added
> the possibility to use a separate HttpState and invoke
> HttpClient#executeMethod passing it as a parameter. The changes keep the
> kernel backward compatible. I did and several tests and it looks good.
>
> Please, give me your comments. Do you like this extension? If so I can
> provide you with the changes and finally we can agree on committing them
> into the kernel.
If I understand correctly you need to use the
public int executeMethod(org.apache.commons.httpclient.HostConfiguration
hostConfiguration, org.apache.commons.httpclient.HttpMethod httpMethod,
org.apache.commons.httpclient.HttpState httpState)
instead of two parameter method if the http state is stored at
serviceContext.
I think you have a valid use case there which can not provide with current
configurations.
Please create a jira and attach the patch.
thanks,
Amila.
>
> Thank you,
> Dobri
>
> [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg45787.html
> [2]
> http://www.mail-archive.com/httpclient-users@hc.apache.org/msg01944.html
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/