hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <e...@zusammenkunft.net>
Subject Re: Side effects of ignoring JSESSIONID in a multi-threaded application
Date Mon, 03 Apr 2017 10:14:50 GMT

I fully agree with both: it is typically a good idea to turn off cookie handling if you know
your requests have to be statelessly processed and it is a warning sign if the server issues
sessions when it should not need to. (There might be however some cache advantage of sticky
sessions so make sure to discuss this with the backend developers before dismissing the need
for Session stickiness)

From: Ferez <f.mahdikhani@dotin.ir>
Sent: Monday, April 3, 2017 11:55:35 AM
To: httpclient-users@hc.apache.org
Subject: Re: Side effects of ignoring JSESSIONID in a multi-threaded application

On 3/19/2017 11:20 PM, Shawn Heisey wrote:
> 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.

Shawn, I agree with you that the JSESSIONID is created by one of the
servers and not the load balancer itself. I should have mentioned that
in a correct way.

> 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.
> https://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
> 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.
Actually I don't have any login process and as I mentioned I use
HttpClient in a request-response way. I mean, I send a request and I
just want the response send back to the requester and the future
requests are not related to this request. So, keeping requests from an
individual user locked to one server is not the case for me, I think.

> 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.
> Thanks,
> Shawn
This is a very good point which I have not taken into consideration
previously, I should check that of course. Thank you very much Shawn

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message