Re: Session serialization and clustering

2014-05-23 Thread Martin Grigorov
Hi,

There is nothing to configure in Wicket.
All you need is to make sure that your Wicket Session is bound (see
Session#bind() method). This will create a Http Session and save Wicket's
Session as attribute in it.

Usually it is recommended to use normal member variable in Wicket Session
instead of using Session#setAttribute() because the latter works with
java.lang.Object. But if you use private Long userId; then you need to call
Session#dirty(true) when you change its value.

Martin Grigorov
Wicket Training and Consulting


On Fri, May 23, 2014 at 4:29 AM, Niranjan Rao nhr...@gmail.com wrote:

 Greetings,

 On wicket 1.5.10 and tomcat 7.0.39 as server.

 Right now my goal is to maintain the authenticated session when web
 application is reloaded for some reason as long as session expired. In
 other words, if we refresh the application, logged in users should not have
 to login again.

 I was reading up on this and it looks like same problem applies to
 clustering as session state needs to be serialized across multiple nodes.
 So far, I could not find a definitive way how to configure wicket. My
 search skills must be going south as I am sure this is a common problem for
 production systems.

 I have changed tomcat configuration so that it can persist the session
 information. For my application purposes we just have userid as a session
 variable. User id is set using setAttribute call when user signs in to the
 application. For practical purposes, all pages are stateless as majority of
 the pages are actually ajax service calls. The containers that makes
 these calls don't change much. So not too much worried about wicket data
 serialization.

 When tomcat serializes data, these values are not getting serialized, so
 when application is refreshed/redeployed, user is forced to login again.
 Interestingly enough, when tomcat is restarted, it works correctly. When I
 just copy new war file or ask tomcat manager to reload, it does not work.

 I tried adding writeObject method in my session class. Log statements in
 this method indicate that getAttribute call returns null.

 Can you please help me to solve this problem or point my nose in right
 direction/documentation.

 Regards,

 Niranjan

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Session serialization and clustering

2014-05-22 Thread Niranjan Rao

Greetings,

On wicket 1.5.10 and tomcat 7.0.39 as server.

Right now my goal is to maintain the authenticated session when web 
application is reloaded for some reason as long as session expired. In 
other words, if we refresh the application, logged in users should not 
have to login again.


I was reading up on this and it looks like same problem applies to 
clustering as session state needs to be serialized across multiple 
nodes. So far, I could not find a definitive way how to configure 
wicket. My search skills must be going south as I am sure this is a 
common problem for production systems.


I have changed tomcat configuration so that it can persist the session 
information. For my application purposes we just have userid as a 
session variable. User id is set using setAttribute call when user signs 
in to the application. For practical purposes, all pages are stateless 
as majority of the pages are actually ajax service calls. The 
containers that makes these calls don't change much. So not too much 
worried about wicket data serialization.


When tomcat serializes data, these values are not getting serialized, so 
when application is refreshed/redeployed, user is forced to login again. 
Interestingly enough, when tomcat is restarted, it works correctly. When 
I just copy new war file or ask tomcat manager to reload, it does not work.


I tried adding writeObject method in my session class. Log statements in 
this method indicate that getAttribute call returns null.


Can you please help me to solve this problem or point my nose in right 
direction/documentation.


Regards,

Niranjan

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org