hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Caching stateful HTTP clients in a pool
Date Sun, 25 Jan 2015 17:12:17 GMT
On Sat, 2015-01-24 at 16:50 +0100, Michael Osipov wrote:
> Am 2015-01-24 um 12:29 schrieb Oleg Kalnichevski:
> > On Fri, 2015-01-23 at 23:36 +0100, Michael Osipov wrote:
> >> Hi folks,
> >>
> >> I am looking for a design decision to cache session information for a
> >> request workflow embedded in a SOAP/REST-based webapp.
> >>
> >> Here is a little background how the workflow is structured and what I am
> >> trying to solve:
> >>
> >> Note: I have read the entire tutorial and am somewhat overwhelmed by the
> >> amount of features the HttpClient has to offer, so I beg your patience.
> >>
> >> Workflow:
> >> 1. Client issues a request either with SOAP or REST with an object id
> >> 2. Server accepts request and does the following:
> >>    2.1. Create a client with a cookie manager
> >>    2.2. Login to a backend server A (HTTP request, server A)
> >>    2.3. Read object information (HTTP request, server A)
> >>    2.4. Obtain a read ticket for a HTTP-based remote store (HTTP request,
> >> server A)
> >>    2.5. Download file behind object id to disk from remote store (HTTP
> >> request, server B)
> >>    2.6. perform a logout (HTTP request, server A)
> >>    2.7. Close the client
> >> 3. Respond to client with object information and the stream from the
> >> saved file
> >>
> >> The entire communication with the server A is stateful with a session
> >> cookie, all responses are fully consumed either with a response handler
> >> or with a try-with-resources clause.
> >>
> >> The problem: the login/logout requests consume around 10 seconds,
> >> sometimes even more. I'd like to avoid this every time.
> >>
> >> My idea was to come around this with Commons Pool 2 which I have already
> >> used for some other session pooling successfully.
> >>
> >> Requirements: it is not only necessary to maintain the cookie store but
> >> a client id header which has a randomly generated integer assigned plus
> >> a request counter. The maintained session has to be used by one thread
> >> at the same time, same applies for the header otherwise server A would
> >> queue all requests. The pool would guarantee that.
> >>
> >> Two possible solutions come to my mind:
> >>
> >> 1. Save the client id and cookie store in the pool and always create a
> >> new client.
> >> 2. Save the client id along with the authenticated HttpClient and reuse it.
> >>
> >> Both solutions will always increment the request counter of course.
> >>
> >>   From HttpClient's view which makes more sense here? What if I go with
> >> option 2, will I have stale connections, clients, etc.?
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >
> > Hi Michael
> >
> > How about a slightly different approach? Consider using one HttpClient
> > for all sessions and maintaining a pool of HttpContext instances with a
> > cookie store / session id.
> 
> Hi,
> 
> thanks for this tip, you are proposing a very interesting approach which 
> I have not considered due to missing knowledge.
> 
> I would have to do the following/solve following questions:
> 
> 1. Create a vanilla HttpClient in my beans.xml as a singleton. Please 
> note that the web application can run for days if not even for weeks and 
> the HttpClient would remain open. That is not a problem?

No, it should not be. You should however consider employing a connection
evictor thread as described here:

http://hc.apache.org/httpcomponents-client-4.3.x/tutorial/html/connmgmt.html#d5e405


> 2. To make the client above usable concurrently, would I need to create 
> a connection pool? I do not intend to use long-lived connections to 
> server A.

You do not have to create a connection pool. HttpClient uses a pool of
connections by default.

> 3. Before login is called, I assign a cookie store to the HttpContext [1]?
> So I would still need to carry on the cookie store plus increment the 
> request counter and supply the client id to the HTTP request?

You just need to create a separate CookieStore per HttpContext.

>  Maybe even 
> with an interceptor [2]?
> 

Quite likely.

> I am having trouble to understand the difference between HttpContext and 
> HttpClientContext.

HttpContext is effectively just a hash map. HttpClientContext is merely
convenience class that makes that map behave more like a POJO.

>  Especially moving the bits off the client to the 
> requests itself though the manual is really good on this one.
> 
> Moreover, I am also inclined to create a seperate client for server B 
> because this one is stateless or doesn't it make a difference because 
> the connecion pool is configurable per target host?
> 

In my opinion this should not make a difference.

Cheers

Oleg



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


Mime
View raw message