Jason, On 12/22/15 11:46 PM, Jason Britton wrote: > On Tue, Dec 22, 2015 at 4:01 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> 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.
I can't remember if it will auto-retry; it might depend upon your configuration. >>> 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. This scenario really isn't any different than a clustered environment with two requests going to two different nodes (for any reason, really). I think this answer still stands: >> I think the answer is: you can't. Make your requests as idempotent as >> possible and, when possible, execute the other kinds of requests such a >> way that the first one to execute "wins" and the others fail gracefully. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
