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]
