Thanks for the feedback. You for anyone elses information, after following the instructions here: http://docs.codehaus.org/display/JETTY/Session+Clustering+with+Terracotta
I found that I had to include the terracotta wicket module, as I was getting terracotta exceptions without it. But now clustering with terracotta seems to work, i can shut down the instance im running on and my session is still valid on the other instance. Matej Knopp-2 wrote: > > Hi, > > On Thu, May 1, 2008 at 12:38 PM, richardwilko > <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Im looking into clustering our wicket app and have a few questions. We >> are >> using jetty 6. >> >> 1) We have to use the SecondLevelCacheSessionStore (default in 1.3) for >> clustering to work correctly, is this correct or does it still work with >> a >> HttpSessionStore? > It will work with httpsessionstore, but it's not really recommended to > use. >> >> 2) Wicket just piggybacks whatever we use for session clustering in >> jetty, >> is this correct? So if we use Terracotta or WADI to cluster jetty, >> things >> will just work, is this right? > Yes. But in order to leverage wicket clustering support you have to > configure your container NOT to keep session attributes serialized > after replication. This is default in tomcat, for other containers I'm > not 100% sure. >> >> 3) I've seen a wicket-cluster project in the wicketstuff repo, can >> anyone >> give me any information on this? I'm struggling to find some >> documentation. > Wicket-cluster is a simple session replication implementation for > Jetty. It can be considered a simpler alternative to WADI. It also > contains a special clustered diskpagestore, but that is irrelevate > with the most recent wicket version (as the pagestore clustering > support is built-in to wicket to work independently of containers). > >> >> 4) If we use Terracotta, does this mean we have to follow the >> instructions >> here http://www.terracotta.org/confluence/display/integrations/Wicket >> too? > Perhaps. But this clusters actual wicket calls, so you'll get lot of > overhead. I've was curious and been profiling this and the result was > that clustring wicket applications with terracotta was lot slower that > simple http session replication. but I'm not a terracotta expert, my > setup might have been flawed and I don't really have any numbers (been > quite some time ago). > > Still, due to the way secondlevelcachesessionstore works, simple > session replication is IMHO much better alternative for Wicket. > DiskPageStore serializes pages anyway (clustered environment or not) > and we cache the serialized data during session replication, so there > is very little overhead in regards of pageserialization if you deploy > a wicket application on a cluster. The only thing to consider, as I > mentioned before, is to configure your container to deserialize > session attributes immediately after being replicated to another > cluster node. Wicket uses this to save the serialized page to target > node's diskpagestore. > > -Matej >> >> Thanks for any help anyone can give me. >> >> Richard >> -- >> View this message in context: >> http://www.nabble.com/A-few-clustering-questions-tp16993201p16993201.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Resizable and reorderable grid components. > http://www.inmethod.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/A-few-clustering-questions-tp16993201p17010177.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
