using JSESSIONID from the upstream server

[sebastien THOMAS]

I tried using "JSESSIONID" cookie name as the sticky hash key to use the cookie set by our java application upstream. Problem is, on the first connexion, the cookie is not there. I thought that the scenario would be :

• http request reach nginx without cookie set
• as no cookie set, connextion is proxied to "one of the" upstream
• for the second request, the cookie is set, so nginx will compute which upstream server to use, which may not be the same one as for the first request

Conclusion is : for this plugin to work with external cookies, a hash map have to be saved and looked up for every request.

Extending this thought, if you have multiple nginx in parallel and proxying to the same upstreams, you need a key store like memcached or redis to share the hash map between every nginx involved....

any way to implement this ?

[sebastien THOMAS]

just saw how HAproxy is doing it, which is smart : when no cookie is present in the request, haproxy wait for the answer of the upstream. Let's say the upstream S1 add the cookie JSESSIONID=qwert Then, HAproxy will prepend the upstream name to the value of the cookie. the client will receive a JSESSIONID=S1~qwerty

On the next request, HAproxy will check the cookie, use the server name to define the upstream and remove the S1~ part before sending it to the upstream....

[S. Goodman]

we'll check it. a simple concat would be no problem (me thinks), but for a distributed solution i dunno. the module should always work w/out 3rd-party-dependencies

[Yarkov]

I don't see the need to reuse a cookie name. JSESSIONID has nothing to do with the upstream selected, and any concatination tries to save two pieces of information under one key. Also, the procedure is the following:

• request reaches nginx without cookie set
• no cookie set, select upstream, set cookie with that upstream
• next request: read cookie and connect to specified upstream

Please provide a usecase were your behaviour is actually needed and provides a benefit.

[Alexander B]

Hi, was just passing by.

Sebastien probably works with tomcat. When tomcat instances are load-balanced with apache, they are tuned to use "jvmRoute" config parameter.

E.g. tomcat no.1 has jvmRoute="n1" and no.2 has "n2".

This parameter influences on JSESSIONID cookie which is assigned by tomcat: JSESSIONID=86DAA07C4928D38C4C6D942DE2EFD111.n2;

Apache configuration knows about which instance is n1 and which is n2, and can route requests to proper node.

[Lazy DogTown]

using this method (i know this from other reverse-proxies and too think it's smart) would require to extend the core-functionality of this module, and we will not implement it at this moment.

we'll consider it for version 2.x, but it is not on our near-time-roadmap; expect it at the end of this year.

i'll leave this ticket open until we have this functionality and to keep you informaed; thanx everyone for participating.

[Sebastián Treu]

Any update on this issue?

[Nick Tan]

same use case there, i just want to reuse the existing tomcat JSESSIONID

looks like this project stops activity since 2016...