Hi, Thanks for all answers. I created a custom Valve for this purpose and it seems to work great in early testing. Hopefully we can configure this easier in a future version of tomcat.
Many thanks! /Johan Rainer Jung-3 wrote: > > On 19.05.2010 20:12, JohnRiley wrote: >> >> Ok, even if I execute a jsp-page in tomcat root and get a cookie with >> path=/ >> I get this problem so it has nothing to to with sharing sessions between >> applications or cookie not reaching it correctly. Things just seems to >> stop >> working properly when I add emptySessionPath="true". >> >> Any idéas? > > Yes: emptySessionPath does two things: > > - it sets the cookie path to "/", so that all contexts receive the same > same session cookie > - if a context gets a cookie and doesn't already have a session with the > requested ID, it creates a new session with the requested ID. > > The second feature is where it fails for you, because now the jvmRoute > is wrong. > > I would try working around using a servlet filter, but I'm not sure, how > early in request processing emptySessionPath kicks in. > > There is a patch proposed for inclusion in TC 6 to make the session > cookie path configurable. Not unlikely it will make it into 6.0.27. You > can have a look at > > http://people.apache.org/~markt/patches/2010-05-18-bug48379.patch > > Regards, > > Rainer > >> JohnRiley wrote: >>> >>> Right on target. I noticed that it was the emptySessionPath="true" that >>> messed things up for me. When I removed it I got back to the wanted >>> behavior. However, the emptySessionPath is needed since we are using >>> mod_rewrite to change the url:s of the backend application. Otherwise we >>> get a JSessionID with a "/path" rather than "/". >>> >>> When I removed the emptySessionPath we got back a new cookie with the >>> correct route. When I have it on I get no sessionId back at all. So the >>> solution would be that the root-context and my application should have >>> the >>> same JSESSIONID (is it possible) or I can deploy my applicaiton in the >>> root directory. >>> >>> /Johan >>> >>> >>> >>> Rainer Jung-3 wrote: >>>> >>>> On 18.05.2010 12:35, JohnRiley wrote: >>>>> >>>>> Hi, >>>>> >>>>> We are load balancing 3 non-clustered tomcat 6.0 servers with the >>>>> mod_jk >>>>> connector in apache 2.0. We have sticky sessions enabled and it works >>>>> fine >>>>> until one of the servers goes down. What happens then is that it start >>>>> round-robin between the other two since none of them wants to accept >>>>> the >>>>> JSESSIONID with the route of the crashed tomcat server. >>>>> >>>>> How can I make one of the other servers to create a new session with >>>>> its >>>>> own >>>>> jvmRoute for that tomcat? Because right now we have a huge problem >>>>> when >>>>> taking down a server for maintenance. The user will change server on >>>>> each >>>>> request until the server that is down for maintenance is back up >>>>> again. >>>>> >>>>> Do we really have to setup the tomcats in a cluster to accomplish >>>>> this? >>>> >>>> Not sure I understand the real problem. If the app does "not accept" >>>> the >>>> sessionid, I would expect it to create a new session (and a new >>>> sessionid) using the correct local route. >>>> >>>> Do you use emptySessionPath in the connector configuration inside >>>> server.xml? >>>> >>>> Can't you add a simple servlet filter overwriting the JSESSIONID cookie >>>> if it's route doesn't match the local route? >>>> >>>> Regards, >>>> >>>> Rainer >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- View this message in context: http://old.nabble.com/mod_jk-session-stickiness-on-failover-tp28594156p28619894.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
