Re: Wicket and tomcat cluster
Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
Re: Wicket and tomcat cluster
If you go non-sticky you'll need to experiment with RenderStrategy. Each has it's pros and cons, and I don't have experience to advise you further. Yes if you want the user to interact with more than one page at a time you'll need to make sure they're all available. You'll also need to replicate synchronously to all nodes. Since Wicket is a stateful framework, it's simply not well-suited to nonsticky deployment IMO, and you should just enable stickiness. In the off chance of a server failure user loses some page history, but at least they stay logged in and don't lose their current activity. I've wondered at possibility of replication listener on failover nodes that maintains complete local disk page store. Not sure if/which containers provide such hooks. Dan On Mar 29, 2013 1:06 AM, Marios Skounakis msc...@gmail.com wrote: Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
Re: Wicket and tomcat cluster
Thanks, things are a lot clearer for me now. On Fri, Mar 29, 2013 at 4:28 PM, Dan Retzlaff dretzl...@gmail.com wrote: If you go non-sticky you'll need to experiment with RenderStrategy. Each has it's pros and cons, and I don't have experience to advise you further. Yes if you want the user to interact with more than one page at a time you'll need to make sure they're all available. You'll also need to replicate synchronously to all nodes. Since Wicket is a stateful framework, it's simply not well-suited to nonsticky deployment IMO, and you should just enable stickiness. In the off chance of a server failure user loses some page history, but at least they stay logged in and don't lose their current activity. I've wondered at possibility of replication listener on failover nodes that maintains complete local disk page store. Not sure if/which containers provide such hooks. Dan On Mar 29, 2013 1:06 AM, Marios Skounakis msc...@gmail.com wrote: Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
Re: Wicket and tomcat cluster
Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
Re: Wicket and tomcat cluster
Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.comwrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
