I meet a trouble in the sticky mode

[GoogleCodeExporter]

The scene is as below:
1. Start two webservers（t1,t2) for this test
2. Submit a request to t1（the loadbalancer does）,then create a session with 
key-value <"a","hello"> on it
3. Shutdown t1 and submit a new request to the loadbalancer,then the request is 
successfully dispatched to t2. (in sticky mode,t2 will load session from the 
memcache server) 
4. Startup t1 and make a new request.At this time,the loadbalancer will 
dispatch the request to t1,according to the route info stored in its 
memory,then t1 will load the session from memcache again. 
5. Change the session from <"a","hello"> to <"a","world"> on t1
6. Shutdown t1 again,as step 3 describes,new requests will be dispatched to t2. 
At this time,I meet the disappointment,
the value of the session is still the <"a","hello">（because the session has 
already in t2's jvm ）,all changes on t1 have been lost 

Original issue reported on code.google.com by ydfa...@hotmail.com on 15 Sep 2011 at 2:06

[GoogleCodeExporter]

The issue is caused by step 4, where the LB does not dispatch the request to 
the last node it sent the client. This is just wrong. A reason might be that 
the session id changed (jvm-route) when the other tomcat took over the request, 
and that the LB is not aware of the jvm-route / does not strip it off. What LB 
is it btw?

Btw, in the case you haven't found it - the mailing list is here: 
http://groups.google.com/group/memcached-session-manager

Original comment by martin.grotzke on 15 Sep 2011 at 9:17

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

LB is haproxy.
I guess that haproxy will store the first server in its'memory,then when the 
first server starts up again ,the request will be taken over by the first 
server again.
is it correct? 

Original comment by ydfa...@hotmail.com on 16 Sep 2011 at 1:14

[GoogleCodeExporter]

I can't tell, you should clarify this on the haproxy list.

You should also check the HTTP request/response headers for each check.

Also the question is how you have configured stickyness.
If you're using appsession you must ensure that only the relevant part of the 
JSESSIONID is used, and neither jvmRoute nore msm node-id are taken into 
account. Assume you have a JSESSIONID "123456-n1.app01" 
(<sessionId>-<nodeId>.<jvmRoute>) only the first part ("123456") must be 
checked by haproxy (e.g. by specifying appsession JSESSIONID len 6), as 
otherwise haproxy would loose track on memcached failover or tomcat failover.
See http://code.google.com/p/haproxy-docs/wiki/appsession for more.

Alternatively you can use the cookie based approach (cookie SERVERID insert 
...): http://code.google.com/p/haproxy-docs/wiki/cookie

You should clarify on the haproxy list which approach is the best and what's 
exactly the problem, as I'm no haproxy expert (only played with it).

Still, I'd be interested what the actual problem here is / was, so it would be 
nice if you could share your findings on the mailing list then: 
http://groups.google.com/group/memcached-session-manager

Original comment by martin.grotzke on 16 Sep 2011 at 7:04

[GoogleCodeExporter]

OK,thanks

Original comment by ydfa...@hotmail.com on 16 Sep 2011 at 8:41

[GoogleCodeExporter]

Original comment by martin.grotzke on 26 Sep 2011 at 10:13

• Changed state: Invalid