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" <[email protected]> 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 <[email protected]> > wrote: > > > Sorry I mistyped: default is REDIRECT_TO_BUFFER. > > > > On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff <[email protected]> > 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 <[email protected] > > >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 > > >> > > > > > > > > >
