Win a copy of Functional Design and Architecture this week in the Functional programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Can we rely on session replication in tomcat ?

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let us say we have session replication set up in a cluster of tomcat having multiple nodes.
While the replication of a session is in progress, a request comes to a node which is not aware of the session (as replication is not complete).
In such a case, what does tomcat do ? Does it hold the request till session replication completes or just proceed with the request ?
 
Saloon Keeper
Posts: 7089
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would suggest not to worry about this particular issue - how fast would the requests have to come in for the replication not to have happened?

Don't replicate between more than 3 Tomcats, though - that's roughly the point where performance starts to suffer.
 
Sushant Kunwara
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But in case, such a scenario happens , what will be behaviour of tomcat ?
I was curious to know.
 
Tim Moores
Saloon Keeper
Posts: 7089
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the session is not there because it has not been replicated to that particular host, then it is up to the code to decide what would happen. It will probably start a new session.
 
Saloon Keeper
Posts: 24283
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The session ID is passed back and forth between client and server (or in this case, server cluster) in the "jsessionid" cookie value or appendage to URL, depending on whether you used cookies or URL rewriting.

The session ID itself is just a "random number" and and can and will change values over time, which is why it has to be passed back and forth for each request/response cycle and cannot be cached.

The session ID is effectively a hash key so that when a request comes in, the proper session can be looked up in a map of HttpSession's.

For a single Tomcat server, the HttpSession map can simply be a HashMap, but in a cluster, the map get() method has to be more sophisticated, since the previous request/response might have been made on a different machine, and thus the current session would be potentially located in that machine's hashmap instance, instead.

To manage this, then, Tomcat's clustering protocols thus have to have a way to locate the current HttpSession within the cluster, and if it's not the machine receiving the current request, the HttpSession has to be serialized out from the machine with the up-to-date-copy and into the current machine. That's one of the reasons why all objects in session scope have to be 100% serializable.

Figuring out which server has the current HttpSession is, of course, a network-based activity, since multiple JVM's cannot share a single object memory space. It's up to the session manager to determine whether this determination is done via "push" - for example, by broadcast/multicast, or by "pull", where each server queries the other servers. As I recall, Tomcat's clustering functions are plug-replaceable, which is one reason why I'm speaking very much abstractly.

There's an additional hitch. A web page request typically has many - often dozens - of sub-requests, such as for CSS, javascript, images and so forth all of which will be made more or less simultaneously. So if the server load balancer doesn't route all of them to the same machine, then multiple servers may all have to have the latest HttpSession for the user and if more than one of them updates the session, it means that the updates need to also propagate in ways that don't conflict. Actually, that's true even for multiple requests to a single machine. but the likely complexity and overhead is much lower. Fortunately, most apps will only have one URL request in a page doing heavy-duty work, so it's not as big a problem as it might be. The JEE specs should address that consideration, I hope.


But in short, an HttpRequest cannot be dispatched until the server it's routed to has been brought fully up-to-date with the latest HttpSession information and thus must remain in the request queue until that happens.
 
Sushant Kunwara
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Tim but how will a tomcat node that receives the request, decides to hold it in queue and wait for session replication to complete ?
I mean how does it even know that the JSESSIONID in the request so received will be replicated to it soon (and hence it holds that request in the queue)?
Session replication can be an ongoing activity and might never halts in that tomcat cluster.
 
Tim Moores
Saloon Keeper
Posts: 7089
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think a Tomcat instance that has been set up for session replication will wait if it receives a request with an unknown session ID. While it could be that the ID is for a session that has not yet been replicated to it, it could just as well be that the ID refers to an expired session. Thus waiting may accomplish nothing. I think it's likely that it will handle the request like it would any other request, possibly creating a new session.
 
Tim Holloway
Saloon Keeper
Posts: 24283
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Session replication" is the process of serializing an HttpSession out of one Tomcat instance and into another. And, as I said, an incoming HttpRequest CANNOT be serviced properly until the latest copy of the HttpSession is resident on the machine holding the request.

So Tomcat's session manager is more or less obliged to query the cluster to see if it needs a replica. One would hope that if the cluster is using "push" technology, it can still "pull" as well, since otherwise the alternative is to park the request until a suitable replica come in and gets installed into the session map.

Again, the Tomcat clustering facility is a plug-in, and so different strategies are possible, including ones that a suitably qualified systems developer might concoct in-house. The only absolute requirement is, again, the session MUST be available when the request is serviced. How it gets there and what sort of delays may be involved are not part of the contract.

And to amplify what I said earlier, Tomcat doesn't stream incoming HttpRequests directly from client to webapp. Each request passes through a series of stages and transformations and at least 2 tuneable pools - one for the incoming network connections and one for the digested HttpRequests waiting for an available Tomcat worker thread. Because webapps are not programs - they run as service requests.
 
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic