Zeus Products > Zeus Traffic Manager

JSESSIONID Persistence failing: Wrong node

(1/1)

cablecartman:
Hi there,

We've got several pools of Glassfish appservers behind our Stingray load balancer, with multiple nodes in each pool. The pools are selected based on context root based rules. I've attempted to use "J2EE Session Persistence" to ensure sessions are routed back to the correct (same) node in each pool after a session is established.

While this works most of the time, it often fails - such that after a session is created on one node, requests are sent to another node in the pool instead of the original node. For some reason, "J2EE Session persistence" appears to be failing.

I've tried "Transparent Session Affinity" and the problem doesn't seem to occur. Requests are correctly routed back to the original node. However, I really need to get "J2EE Session persistence" working (for a bunch of other reasons). I'm not sure what's going on to cause Stingray to route the requests to the wrong node. As I said, it mostly works, but mostly isn't good enough (obviously) and I'd love to understand what's going on here (and why Transparent Affinity works).

Any ideas or suggestions would be most appreciated!

karthy:
Hi

Two reasons come to mind - do any of the backend nodes fails? If a node fails, the session might migrate to another node (configuration option). Try to check your errorlog to be certain!

The other reason could be, that the session pool is hitting the max size - on the activity monitor, you can graph the max age of session in a sessioncache - if you have sessions older than this max age, then you have reached the max size and you should increase the size (system setting and be aware, that it will take a bit more memory).

Let us know hos it goes.

Br,
Karsten

Owen:
Hi,

Transparent session affinity works by inserting a tracking cookie into the first response (once the load balancing decision has been made and the node selected).  If that cookie is present in subsequent requests, then the request is routed to original node.  It's simple and reliable, but does not work in cases where clients do not support or honor cookies.

J2EE Session Persistence works by locating the J2EE Session ID, which may be found either in the URL or a cookie.  This session ID (and the selected node) is shared across the cluster using a cache (j2ee_cache_size determines the size of the cache).  As Karsten points out, you may need to increase the size of the cache, as the default (2048 entries) is rather small.

If you can replicate the problem, then you can use the request logging to understand what is happening.  There are three relevant values that may be logged:

%F     The favored node for this connection 
%n     Node that was used for the connection 
%N     Node required to handle this connection (because of session persistence) 

If session persistence applies, %N will tell you the persisted node and this should match %n (the selected node) unless that node has failed.  In that case, the failuremode setting of the persistence class will define what the traffic manager does.

%F indicates a weekly-preferred node.  If there is no session persistence selection in effect (for example, it's the first request in the session), then we apply heuristics such as preferring the node that most recently responded to the same URL.  These influence the load balancing decision, but are not mandatory and will be ignored if a different node is strongly favoured by the load balancer.

Best regards

Owen

Navigation

[0] Message Index