The current terracotta integration does use the HTTPSessionStore, infact the integration module forces the HTTPSessionStore using the bytecode manipulation stuff it uses.
What i've found is that the key with any terracotta clustering is that you cannot cluster page objects as this causes too much garbage, instead you have to cluster a byte array of the serialised page object instead (this is what my new IPageMapEntry implementation does). Would replacing the disk based store in the default session store with one that stores serialised pages in some sort of terracotta distributed map in memory work? Although would that still leave the last accessed page as a page object in memory? Cheers, Richard Matej Knopp-2 wrote: > > Hi, > > the thing is a bit more complicated than just that :) I'm not sure how > Wicket terractotta integration works currently. Last time I checked it > was recommended to use HTTPSessionStore which itself is a big drawback > as the HTTPSessionStore has certain backbutton problems that can not > be resolved at least until 1.5. > > As for DiskPageStore, Wicket itself contains support for session > replication that is however targetted to "regular" clusters assuming > that after each request changed session properties are serialized and > replicated to backing nodes (and preferably immediately deserialized - > explanation below). > > DiskPageStore's purpose is to store serialized pages on disk in order > to allow access to previous page versions and also to conserve session > memory usage. So DiskPageStore serializes page during each request. > The serialization happens whether wicket runs on cluster on not. > However, when wicket is running on cluster, the already serialized > data is used during session replication, so the pages are not > serialized again. This is an important optimization that is resulting > in fact that there is no additional serialization penalty when running > wicket on (regular) cluster. > > When target node receives the serialized session entries during > replication and deserializes it (it is recommended to configure the > container to deserialize session properties immediately) the page > itself is not really deserialized. It is only stored in target node's > diskpagestore, so there is no page deserialization happening and the > actual page data is not held in memory on target node. > > This is roughly the idea of running Wicket application on a standard > replicated cluster. Now I'm not sure about TC, but IIRC the default > Wicket TC setup used HTTPSessionStore (which doesn't contain any > "special" support for session replication). > > I think it would be very nice to have TC leverage the existing > replication support of Wicket's DiskPageStore acting more like a > simple session replication. WDYT? > > Cheers, > -Matej > > On Sat, Jun 28, 2008 at 10:31 AM, Ari Zilka <[EMAIL PROTECTED]> > wrote: >> Hello all, >> >> I work for Terracotta on JVM-level clustering type stuff. I recently >> spoke >> with a Wicket + TC user who went to production and uncovered a nasty >> surprise. I wanted to propose to this community that we consider >> incorporating the changes he needed to make in order to cluster and scale >> well. >> >> He--Richard Wilkinson--documented his changes on his blog here: >> http://www.richard-wilkinson.co.uk/2008/06/22/more-on-terracotta-and-wicket/ >> >> I look forward to discussing the possible ways forward. >> >> Cheers, >> >> --Ari >> > > -- View this message in context: http://www.nabble.com/Terracotta-integration-tp18168616p18191341.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
