Jason, On 12/21/15 12:22 PM, Jason Britton wrote: > Following back up after perusing Chris' very helpful presentation ( > http://people.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf) > on > load balancing tomcats with mod_jk. > > One part not mentioned was session fail over.
Correct. I lump that in with "clustering", which was explicitly out-of-score for the 50-minute presentation at ApacheCon. Mark covered it a bit in his 3-part presentation at the same conference. Have a look at the 2015-04-15* presentations here: http://home.apache.org/~markt/presentations/ Also possibly here: http://home.apache.org/~markt/presentations/2014-11-20-Tomcat-load-balancing-and-clustering/ > Which my current plan is to > use JDBCStore for persisting to a database table shared by all tomcats > powering apps. But this has brought up a couple concerns... If while a > tomcat node is being shut down and triggered by this shut down tomcat is in > the middle of writing out session data to the JDBCStore, a request from a > client that was using that node comes in, mod_jk tries to route the request > to the node that is shutting down but mod_jk's configured connect_timeout > times out waiting and mod_jk then routes to another node (hopefully that's > how this works). So mod_jk routes a request to the node which is going down, and then decides to re-route because the connection times-out? Just making sure I have that all in my head (it's an awfully long sentence). > A different active tomcat node now receives the request > and tries to reconstitute the user's session from the same shared > JDBCStore, but what if the first tomcat node is not finished shutting down > and has not finished writing out this particular user's session data yet? > How can we ensure that session data will be there? Although I'm not entirely sure of the behavior of Tomcat's clustering features in that particular case, you are mostly asking the following: "what happens if two nodes are essentially sharing a session? how do I make sure their view of the session is consistent?" I think the answer is: you can't. Make your requests as idempotent as possible and, when possible, execute the other kinds of requestssuch a way that the first one to execute "wins" and the others fail gracefully. > From looking at the config of the Manager, there is a maxIdleBackup > parameter that I imagine could be set to 0 but I'm a little wary of the > possible performance implications. Its description: The time interval (in > seconds) since the last access to a session before it is eligible for being > persisted to the session store, or -1 to disable this feature. By default, > this feature is disabled. Even if this was ok from a performance > perspective, once a session was initially persisted, would its session data > be updated in the session store on subsequent changes/requests? Even if you update every time the background thread runs, that thread is doing a handful of different things and you might not get that real-time feeling you are looking for. Session data will be updated if you call session.setAttribute() or session.removeAttribute (or equivalent) during the request. If you have a HashMap in the session and you call ((Map)session.getAttribute("myMap")).put("foo", "bar") then your session will effectively change only on the node where that request was being served. If you want to persist those changes to other nodes (e.g. using BackupManager) or to a Store, then you'll need to do the equivalent of: session.setAttribute("myMap", session.getAttribute("myMap")); This will poke the cluster manager to do whatever is appropriate to push the session to other places (db, other Tomcat server, memcached, etc.). > I've read about some folks configuring valves for shared in-memory caches > (redis), I'm not sure I want to go that route at this point. You only want to do this kind of thing if two items apply to you: 1. You need better performance than a disk-based db can provide 2. You can afford to lose everything if a process dies Uaually #2 is a deal-breaker for people considering "real" clustering; that is, using distributable sessions and not sticky-sessions without distribution or storage of any kind (since otherwise, you would just let people's sessions die when they fail-over). -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
