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?
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.
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? Maybe even
with an interceptor [2]?
I am having trouble to understand the difference between HttpContext and
HttpClientContext. 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?
[1]
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/statemgmt.html#d5e574
[2]
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#protocol_interceptors
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
