Hi Martin,
I think this might have solved it . Many thanks :-)
On Wed, Nov 5, 2014 at 1:49 PM, Martin Grigorov mgrigo...@apache.org
wrote:
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
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.
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
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
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
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 :
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