Thanks ! It is more clear now !
On Wed, Nov 5, 2014 at 3:44 PM, Wayne W <waynemailingli...@gmail.com> wrote: > 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()); > try by adding getSession().bind(); at step 5 > 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 > > > > > > > > > > > > > > >
