Am 2015-01-26 um 10:18 schrieb Oleg Kalnichevski:
On Sun, 2015-01-25 at 22:24 +0100, Michael Osipov wrote:
Am 2015-01-25 um 18:12 schrieb Oleg Kalnichevski:
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
If I won't I might end up in stale connections right? This is at least
what the docs tell me.
No matter what you do there is always a possibility of a connection
getting 'stale' immediately after passing a staleness check. A
combination of a reasonable eviction policy enforced by a background
thread and a reasonable recovery (request retrial) policy should be
sufficient to ensure near 100% reliability of request execution in my
opinion.
Hi Oleg,
first of all, thank you for all the advisories you have given me. They
helped a lot. My implementation is no working and my consumers will
start their tests shortly. I have even achieved to pipe the request
directly from the consumer to the backend server w/o caching as file on
the machine. I am tremendously satisfied by the features HttpClient offers.
Prior to this, I have implemented everything as a JMeter testplan where
HttpClient did a great job.
I have promised to share my approach, this will happen shortly.
Everyone's invited to comment on then.
I am still unclear about the stale conn evitor thread exampled in the
tutorial [1]. Why is this sample code even mentioned if there is already
an evitor [2], [3] built-in? The tutorial implies to me that I need to
write and hook in that background thread.
[1]
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e405
[2]
https://github.com/apache/httpclient/blob/5a192e2bf46bc749d8771a6f16cd40bc34146f24/httpclient/src/main/java/org/apache/http/impl/client/IdleConnectionEvictor.java
[3]
https://github.com/apache/httpclient/blob/529e1373a5a7cc8483862fbfd453f2c567b6362d/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L1167-L1188
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
