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
> > > >
> > >
> >
>
