Then your first mail misleads. Would you please explain again the steps with more details which step on which node happens.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Nov 5, 2014 at 1:01 PM, Wayne W <waynemailingli...@gmail.com> wrote: > 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 > > > > > >
