Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Message-ID: <1423738856.13018.4.camel@apache.org>
Subject: Re: Caching stateful HTTP clients in a pool
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Date: Thu, 12 Feb 2015 12:00:56 +0100
In-Reply-To: <54DBA135.90802@apache.org>
References: <54C2CCEB.3050305@apache.org>
			 <1422098965.26178.3.camel@apache.org> <54C3BF38.5050807@apache.org>
		 <1422205937.6615.3.camel@apache.org> <54C55EF1.20604@apache.org>
	 <1422263933.21142.3.camel@apache.org> <54DBA135.90802@apache.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2015-02-11 at 19:36 +0100, Michael Osipov wrote:
> 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.
> 

I am glad I was of some help.

> 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?

Some people might still want to enforce a slightly different eviction
policy or settings. This naturally requites a custom evitor thread.    

>  The tutorial implies to me that I need to 
> write and hook in that background thread.
> 

One can always add more content to the tutorial.

Oleg


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