Thanks, things are a lot clearer for me now.
On Fri, Mar 29, 2013 at 4:28 PM, Dan Retzlaff <[email protected]> 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" <[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 > > > >> > > > > > > > > > > > > > >
