Hi Steven Unfortunately I havent been using the proxy for balancing for a while now..
But I know it works flawlessly with mod_jk, and if your using jetty you can also get that running. http://docs.codehaus.org/display/JETTY/Configuring+AJP13+Using+mod_jk . Otherwise i'd go to the httpd forum and ask them, you usually get help there :) regards Nino 2010/7/1 Steven Haines <[email protected]> > Hi, > > I just setup my production environment for a wicket-based application today > and > I am having a problem with "Page Expired" messages. I have three servers > that > are not clustered together, but rather are configured with Apache's > proxy_balancer to use sticky sessions (with failover turned off.) The > homepage > always loads, but a high percentage of the time when I enter the second > page of > my application I receive a "Page Expired" page - clicking on that takes me > back > to the home page and then the application works. > > My guess is that when the homepage is loaded that Wicket provides a new > jsessionid (I sometimes see it coming in the submission url) but then the > user > is directed to another server on the next request, and because the user > does not > yet have a JSESSIONID cookie, but does have the jsessionid in the URL, the > Wicket instance that receives the request searches and cannot find the > session > id and marks the page as expired. The next request then populates the > browser's > cookie and the sticky session works.This is just a theory, but it would > explain > the behavior. > > I thought I handled this case in the proxy_balancer configuration with an > entry > like the following: > > ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid > nofailover=On > > Where JSESSIONID|jsessionid covers the cookie and encoded path, > respectively, > and the nofailover=On tells Apache to not to try to fail a user's session > over > to antoher server. > > Has anyone faced this problem? Any ideas on how to resolve it? And we're > going > to start allow production load very shortly, so any insight would be much > appreciated! > > Thanks > > Steve > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
