1 of 1 people found this helpful
You should active the sticky-session in your loadbalancer!
As long as this server works its fine.
If the server crash the LB will choice another server, assuming that everything is configured correct, you might reach the 'backup' server or not.
Now it depends to the server version and configuration what happen.
But in any case the session will be replicated to the server where the request now is
it will be replicated when necessary that you have at minimum one backup (buddy repl) or as many backups as configured
Let me explain IIRC how failover works with distribution mode, say we have 2 copies of data (numOwners, or 'owners' in AS7 subsystem):
- loadbalancer gets a request from a new client without session, according to its LB policy say node A is chosen
- session is created on node A and will be always on node A using Infinispan's KeyAffinity service
- hash will be calculated and say node B will also have a copy, and be a second owner.
- node A is always used because of sticky sessions until server A fails
- currently, the LB is not aware who owns a backup, so a node is chosen by LB policy, say C
- C doesn't own the data so it will do a remote fetch from B known from the hash function
- after request is complete, it will modify jvmRoute (instance-id) for LB to next time failover to B directly
Voila! If your load-balancer supports sticky sessions by the same mechanism i.e. appending the route name after the session, the failover will work with your balancer.
If you are really saying though that you dont have sticky sessions on, that is really bad for performance and general stability. Please enable sticky sessions.
In response to Wolf-Dieter Fink
Sorry for not making clear I'm talking about JBossAS7 / EAP6.
we will use sticky sessions if we go for the "dist-async" mode but I'd still like to know the exact behavior of a server that doesn't hold the session object in its own cache.
You say it will be replicated to whatever server calls for it.
As nice as that sounds to me, it directly conflicts with the design of a predetermined set of 2 servers based on a hash of the key holding the session object.
If what you say is right (I sure hope so) it would mean
- the session object is now in 3 places
- One of the old 2 servers doesn't have it anymore (those being the primary and backup server after server crash)
- There are no predetermined servers, and a single server has no idea what server holds what data
ps. I marked your answer as helpful but I'd still like to know "exactly" what happens.
Thanks Rado for your very complete anwser.
It is as I thought than afterall;
We will need to investigate further into how the specific "jvmRoute (instance-id)" logic can be transferred and interpreted to our specific LB to prevent the session from sticking to the wrong new server.
What LB are you using? In-house?
PS: disregard the previous version of this post, I see you were replying to a different post now.
I updated my post to better reflect that as it seems we cross-posted.