On Tue, Dec 22, 2015 at 4:01 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> 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. > > Understandable > 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/ > > Thanks for these links. > > 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). > > my understanding, could be wrong, that if the connect_timeout is reached by mod_jk that it would try a different node. > > 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 should have clarified the environment I was envisioning was one with sticky sessions, no clustering. And the situation I'm looking to wrap my brain around is one where the once active node is triggered to write out session data due to the impending shut down of the particular node. At about the same time this shutdown is occurring a request comes in for a client that has a session cookie value routing it to the node being shut down. mod_jk times out trying to connect to this node and reroutes the request to an active node. I see a race condition where depending on how long it takes the first tomcat being shutdown to write out session data to the JDBCStore, that the subsequent tomcat node trying to service the request may not find this user's session data in the shared JDBCStore. I'd really like to know if this is truly something to be concerned about, and if so, how to account for it. > 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 > > Usually #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 > Jason
