Manak,
On 12/1/23 03:27, Manak Bisht wrote:
Hi, I am trying to implement non-sticky session replication using Delta
Manager with static membership. The nodes are across two different
machines.
This isn't really relevant to your issue, but I would *always* recommend
enabling stickiness. Why? I'll tell you.
The DeltaManager (and really any clustered Manager) works by listening
for HttpSessionAttributeListener events and, after a request has
completed, distributing the changes to the session across all other
cluster members.
You can almost think of it like an RDBMS transaction: INSERT, UPDATE,
DELETE... then COMMIT. Not until the COMMIT will the rest of the cluster
see the changes.
Your browser will happily make multiple simultaneous requests to a web
service, so there can be multiple requests in flight at any one time. If
these go to different servers in your cluster (because you have disabled
stickiness), then two requests can be modifying the state of your users'
sessions separately on any number of servers simultaneously, and
independently of each other. You cannot predict which request will go
where and when the replication from any source node will occur and take
effect on any destination node.
The situation is sufficiently chaotic that something odd like this may
affect a user:
1. They are looking at a view in your application
2. They choose a "change language" option that switches from e.g.
English to e.g. French
3. The request from (2) above goes to Node X, and the session's locale
changes from "en" to "fr", and the response includes a redirect e.g.
"back to the same page you were just looking at"
4. The client follows the redirect, but hits Node Y in your cluster,
which has not yet received the session-replication-event which includes
the updated locale setting. The response is shown in English, because
that's the value still in the user's session.
5. The user files a bug report, stating "When I changed language, the
change didn't take effect until the SECOND request".
6. Nobody can replicate the problem in dev/testing because either the
dev/test cluster is too fast or you don't bother with clustered sessions
in dev/test.
If you enable stickiness, all requests will be delivered to the same
server and the above situation is extraordinarily unlikely. The only
time your user has to switch servers is if their primary node fails for
some reason. When failover occurs, Strange Things are bound to happen
for a variety of reasons, but those situations are unusual. If you
disable stickiness, those Weird Things can literally happen with /every
request/.
If you have a good reason to disable stickness, I'd love to hear the
reasoning.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
