Sorry Martin its not clear enough. This any better?
1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login (LoginPage.java) 2. Tomcat1 / Session A / Thread 2: They log in 3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a redirect to : foo.example.com/login passing some parameters 4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we verify the parameters and if valid setup up the new current session with the user's details (Session.setUser(user)) 5. Tomcat 2/ Session B / Thread 1: LoginPage then does a setResponsePage(Application.get().getHomePage()); 6. Tomcat 2/Session B / Thread 1: MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds null in the Session (Session.getUser() ) On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > 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 > > > > > > > > > >