hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Side effects of ignoring JSESSIONID in a multi-threaded application
Date Sun, 19 Mar 2017 18:50:56 GMT
On 3/18/2017 8:58 AM, Farzad Mahdikhani wrote:
> I am using a CloseableHttpClient which uses a
> PoolingHttpClientConnectionManager in a web application, I mean a
> multi-threaded application with different users, in a state-less way
> or request-response way. The server at the other hand, a load balancer
> in front of 10 servers which I don’t have control over it, sends a
> JSESSIONID in response. Now, the problem is that the JSESSIONID sent
> by the server is kept by HttpClient and used at the future requests.
> When this happens, the load balancer redirects every request to the
> first server, i.e., the creator of the session id which is not
> appropriate for me and I want other servers to be used by the load
> balancer for other requests (balance the load among the servers). 

Hoping that I have completely correct information.  I *think* that I
have it right.

I do not believe that JSESSIONID is being generated by the load
balancer.  The load balancer might USE thgat cookie, but it is usually
created by a web application running inside a java servlet container. 
An example of such a container is Tomcat.  The cookie is used to allow
the server to maintain session state for the end user -- keeping them
logged in, tracking application state, etc.

Even if the servers have session replication enabled, you generally WANT
requests from a specific user to be handled by the same server, to be
absolutely certain that everything works.  Session replication is a nice
feature, but there are circumstances in which it is not recommended. 
Without replication, keeping requests from an individual user locked to
one server is absolutely necessary.


If you ignore this cookie in the client and the client performs a login
operation, you'll find that a client that has logged in on one request
will no longer be logged in on the next request, because the JSESSION
cookie is how the login session is preserved.

Another potential problem that can be caused by ignoring the session
cookie:  A new cookie will be generated by the server on every request. 
This can eat up memory on the server, because the server will hold onto
each cookie it generates for a while, typically a fewhours or days,
along with session state information for that cookie value.  They will
eventually be cleaned out, but if there are a lot of requests that
ignore the cookie, they may be created a lot faster than they are
cleaned.  If session replication is enabled, then all those useless
sessions will be copied to all servers.


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

View raw message