HostConfig and HttpState questions in multi-threaded environment

["Wellman, Daniel" <Da...@ustrust.com>]

I'm using HttpClient 3.0 rc3 in my web application which communicates
with a 3rd party server over HTTP.  I've been reading through the
archives, code, and documentation, and came up with a strategy for using
HttpClient, and wanted to ask for feedback to see if I'm missing
something.  Thanks in advance for any advice!

My questions:
1. It looks like the HostConfiguration may not be safe to share amongst
different threads, since any redirect changes the HostConfiguration
object.  Right now I create a new HostConfiguration on every
executeMethod().  This feels inefficient; is it?  Is there a better way?
   httpClient.executeMethod(new HostConfiguration(), method, state);

2. When an app-server request requires multiple HttpClient calls, I
create one HttpState and reuse it for all executeMethod() calls.
However, across app-server requests, I wasn't sure if I should embed the
HttpState in my app-server HTTP session, or just the JSessionId.  My
first thought was that storing the user's HttpState in their app server
session might be memory intensive, though now I'm not sure.  Right now I
just store the JSessionId String in the app server session, and create
the Cookie and HttpState when beginning a new series of HttpClient
requests.


Background:
- Since my app runs in an application server, I'm using the
MultiThreadedHttpCommunicationManager.  I store one instance of
HttpClient which all requests reuse, and execute the call using
httpClient.executeMethod(HostConfiguration, HttpMethod, HttpState)

- Each active user session of the web app has at most one open
connection to the server.  The server uses cookies (JSessionId) to
maintain state.  The session has a timeout of 30 minutes, so the session
may change for long app-server sessions. 

- Currently all my HttpClient requests go to one server with the same
path.  I configure my HttpMethods with an absolute URL, which I obtain
the first time via my application's properties.  I realize now it may be
better to have the HostConfiguration store the host name & port, and
each HttpMethod request contain the relative URI.

Thank you for your feedback,

Daniel Wellman


---------------------------------------------------------------------
The message contains confidential and/or legally privileged
information and is intended for use by the indicated addressee.
If you are not the intended addressee: (a) any disclosure,
reproduction, distribution or action you take because of it is
strictly prohibited; (b) please return the complete message to the
sender; and (c) this message is not a solicitation for purchase or
sale or an agreement of any kind whatsoever that binds the sender.
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

Re: HostConfig and HttpState questions in multi-threaded environment

[Oleg Kalnichevski <ol...@apache.org>]

On Fri, 2005-08-26 at 14:58 -0400, Wellman, Daniel wrote: 
> I'm using HttpClient 3.0 rc3 in my web application which communicates
> with a 3rd party server over HTTP.  I've been reading through the
> archives, code, and documentation, and came up with a strategy for using
> HttpClient, and wanted to ask for feedback to see if I'm missing
> something.  Thanks in advance for any advice!
> 
> My questions:
> 1. It looks like the HostConfiguration may not be safe to share amongst
> different threads, since any redirect changes the HostConfiguration
> object.  Right now I create a new HostConfiguration on every
> executeMethod().  This feels inefficient; is it?  Is there a better way?
>    httpClient.executeMethod(new HostConfiguration(), method, state);

Daniel,

Generally we recommend to have one HostConfiguration instance per worker
thread. However, if a cross-site /cross-port redirect occurs, the
HostConfiguration instance gets modified to reflect the final target
host the request was sent to. If you do not want that you may want to
disable automatic redirects. Alternatively you may want to keep the
HostConfiguration instance and reset the target host and port prior to
executing a new request. 

> 
> 2. When an app-server request requires multiple HttpClient calls, I
> create one HttpState and reuse it for all executeMethod() calls.
> However, across app-server requests, I wasn't sure if I should embed the
> HttpState in my app-server HTTP session, or just the JSessionId.  My
> first thought was that storing the user's HttpState in their app server
> session might be memory intensive, though now I'm not sure.  Right now I
> just store the JSessionId String in the app server session, and create
> the Cookie and HttpState when beginning a new series of HttpClient
> requests.
> 

I do not see a big difference if JSessionId is the only relevant cookie.
If you create a new HttpState per series of requests you get more
garbage on the heap but smaller HTTP session. If you keep HttpState in
the HTTP session, you will have slightly larger session object and less
garbage on the heap

> 
> Background:
> - Since my app runs in an application server, I'm using the
> MultiThreadedHttpCommunicationManager.  I store one instance of
> HttpClient which all requests reuse, and execute the call using
> httpClient.executeMethod(HostConfiguration, HttpMethod, HttpState)
> 
> - Each active user session of the web app has at most one open
> connection to the server.  The server uses cookies (JSessionId) to
> maintain state.  The session has a timeout of 30 minutes, so the session
> may change for long app-server sessions. 
> 
> - Currently all my HttpClient requests go to one server with the same
> path.  I configure my HttpMethods with an absolute URL, which I obtain
> the first time via my application's properties.  I realize now it may be
> better to have the HostConfiguration store the host name & port, and
> each HttpMethod request contain the relative URI.

That indeed would be a better way. 

Hope this helps

Oleg

> 
> Thank you for your feedback,
> 
> Daniel Wellman
> 
> 
> ---------------------------------------------------------------------
> The message contains confidential and/or legally privileged
> information and is intended for use by the indicated addressee.
> If you are not the intended addressee: (a) any disclosure,
> reproduction, distribution or action you take because of it is
> strictly prohibited; (b) please return the complete message to the
> sender; and (c) this message is not a solicitation for purchase or
> sale or an agreement of any kind whatsoever that binds the sender.
> ---------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org