Hello, 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)
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Ferez <f.mahdikh...@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-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org