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. 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). 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? >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? 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. Any thoughts would be much appreciated, Jason On Tue, Dec 8, 2015 at 10:43 AM, Kevin Hale Boyes <kcbo...@gmail.com> wrote: > On 4 December 2015 at 11:19, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > Kevin, > > > > On 12/3/15 2:21 PM, Kevin Hale Boyes wrote: > > > Thanks for this link to the presentation. > > > How do you all deal with some of the other dependencies that the web > > > application has? > > > > > > For example, if v2 of my application needs new database columns or > > worse, a > > > change to an existing column how can I have v1 and v2 running at the > same > > > time? We use Oracle as our database though the problem exists for many > > > database servers. > > > > That's not a deployment problem. That's a design problem. > > > > In short, you need to make sure that your web application is both > > forward-compatible and backward-compatible at the same time. > > > > That's rubbish, or course. Here's a more concrete suggestion, and it > > requires a LOT of work, but it's worth it. > > > > First of all, you can't think of a release as a single event any more. > > Instead, there are 4 events. > > > > > We already do this sort of development when needed. In particular, when we > have database changes that will take a long time like back populating new > columns or creating new indexes on large tables, we run then in a > pre-release phase against live production. We time the activities to > finish just before our release window. Sometimes we also have post-release > database activities as well that follow shortly after our release outage. > > I guess I hadn't extended my thoughts far enough and seen the full > potential of the idea so thanks. > One drawback for us when we use this mechanism is related to our release > schedule. We release on a quarterly basis so having a process that spans > four releases pushes it out for an entire year. But that's our problem and > we're making headway there too. > > Thanks Christopher > Kevin. >
