Hi Martin, I don't think this is anything to do with session replication, as we invalidate the session at step 3 and its not about trying to pick the session up on a different instance. Its about creating a new session from a redirect where the issue seems. We do use sticky session load balancing via the JSESSION cookie on apache.
On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > As far as I know the session replication supporting code is the same since > Wicket 1.4.1 (or 1.4.2). > > The Wicket Session object is saved as an attribute in the HttpSession. The > HttpSession is replicated by Tomcat itself. What is your Tomcat config > related to replication ? > Do you use sticky sessions ? It seems you don't but I have to ask. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W <waynemailingli...@gmail.com> > wrote: > > > Hi, > > > > we recently migrated to 6.17 from 4.x. Something we are now experiencing > is > > an odd session problem in production. > > > > We have 2 tomcats load balance running the front end wicket code. We > have a > > certain flow that goes like this: > > > > > > 1. User goes to : my.example.com/login (LoginPage.java) > > 2. They log in > > 3. We invalidate the session and do a redirect to : > > foo.example.com/login > > passing some parameters > > 4. In the constructor of LoginPage we verify the parameters and if > valid > > setup up the new current session with the user's details > > 5. LoginPage then does > > a setResponsePage(Application.get().getHomePage()); > > > > This on a single node/machine/instance of tomcat works great and with > > Wicket 4 it also worked great in a 2 node/instance load balanced > situation > > however we have a problem. > > > > Problem: > > If at step 3 the redirect gets load balances to a different instance of > > tomcat, step 4 works fine (the request is read the the new session is got > > and the user info set on it). But this is when it gets really odd. Step 5 > > is executed fine, but when the home page is constructed > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is > > called as normal, and when we check the session to see if the users > details > > are ok, there is no user in the session at all and we have a different > > session ! > > > > Any ideas at all what is happening here? Did something change around the > > session handling? I'm wondering if its something to do with the 302 > > redirect to the new URL with parameters? > > > > many thanks > > >
