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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
