You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne W <wa...@gmail.com> on 2014/11/05 11:43:58 UTC
Wicket 6 Session issue
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
Re: Wicket 6 Session issue
Posted by Wayne W <wa...@gmail.com>.
Hi Martin,
I think this might have solved it . Many thanks :-)
On Wed, Nov 5, 2014 at 1:49 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Thanks ! It is more clear now !
>
>
> On Wed, Nov 5, 2014 at 3:44 PM, Wayne W <wa...@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 <mg...@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 <wa...@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 <
> mgrigorov@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 <
> > waynemailinglists@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Wicket 6 Session issue
Posted by Martin Grigorov <mg...@apache.org>.
Thanks ! It is more clear now !
On Wed, Nov 5, 2014 at 3:44 PM, Wayne W <wa...@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 <mg...@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 <wa...@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 <mgrigorov@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 <
> waynemailinglists@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
> > > > >
> > > >
> > >
> >
>
Re: Wicket 6 Session issue
Posted by Wayne W <wa...@gmail.com>.
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 <mg...@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 <wa...@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 <mg...@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 <wa...@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
> > > >
> > >
> >
>
Re: Wicket 6 Session issue
Posted by Martin Grigorov <mg...@apache.org>.
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 <wa...@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 <mg...@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 <wa...@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
> > >
> >
>
Re: Wicket 6 Session issue
Posted by Wayne W <wa...@gmail.com>.
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 <mg...@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 <wa...@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
> >
>
Re: Wicket 6 Session issue
Posted by Martin Grigorov <mg...@apache.org>.
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 <wa...@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
>