Just to be complete, even if this is not really an option for us: with ONE_PASS_RENDER clustering with wicket would be fine, no further state management issues, right?
Thanx && cheers, Martin On Mon, 2009-03-09 at 17:15 +0100, Martijn Dashorst wrote: > Non-sticky would be rather bad for Wicket performance/programming model. > > The default of wicket is to redirect after an event to a get request > which renders a buffered response. The buffered response is only > available on the jvm that handled the original request. If the > buffered response is not available, it would require rendering all > content again, requiring fetching all entities, etc. from the > database. > > Martijn > > > On Mon, Mar 9, 2009 at 3:03 PM, Martin Grotzke > <[email protected]> wrote: > > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: > >> Starts to sound like a form of premature optimization. If you are new > >> to Wicket, why do you want to implement a memcached session store? > >> What is the usecase? > > We're starting a new project (the relaunch of a big ecommerce system) > > and want to be able to scale out (just throw in new hardware when > > traffic grows). Additionally we have the requirement of session > > failover, both in standard operations and for deployments. > > > > We're discussing non-sticky vs. sticky sessions here and for non-sticky > > sessions memcached (as caching layer in addition to sessions stored in a > > database) is a good candidate, as you don't replicate the changed > > session to all other nodes, but only to the primary node for this > > session id. This is an important aspect for beeing able to scale out. > > > > Concerning non-sticky/sticky/memcached/whatever we're not decided yet, > > still running in evaluation mode :) > > > > Cheers, > > Martin > > > > > >> > >> Martijn > >> > >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke > >> <[email protected]> wrote: > >> > On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote: > >> >> I wrote a memcached session manager store for jetty, that our wicket > >> >> app utilizes. Works well, except I can't open source it, > >> >> since it was created on the company's dime ;-( > >> > Well, most interesting things are not so simple to realize that one can > >> > do it in its spare time. But the good point is that we can do such > >> > interesting things in our job :) > >> > > >> >> > >> >> Here is my opinion on memcached as a session store. > >> >> > >> >> Memcached will not work well as a wicket session store, due to 1mb > >> >> size limits. > >> > Good to know, I wasn't aware of this restriction (I still need to read > >> > more about this for details). So one is forced to handle resources > >> > eating much memory (e.g. fileupload) not via session, which is the case > >> > even without this 1 mb size limit :) > >> > > >> > Do you have a case where this limit is important especially for wicket? > >> > > >> >> You honestly don't want to serialize anything past 100kb > >> >> in size due to performance reasons. > >> > Right. > >> > > >> >> That said, It works best if you > >> >> use memcached as a container httpsessionstore with the wicket > >> >> secondlevelcache diskpagestore. The only thing you need to serialize > >> >> is the last pagemap which should only be 50kb in size max. You still > >> >> get fail over since the last page map is distributed. > >> > And I have to read about page maps (I'm really new to wicket as you > >> > see :)). AFAIK page maps store a configurable numer of versioned pages > >> > for back-button support and versioned pages. > >> > > >> >> > >> >> One thing you need to be careful with is not referencing anything that > >> >> got stored on disk from your active pagemap, it will spiral into a > >> >> stack overflow. > >> >> > >> >> https://issues.apache.org/jira/browse/WICKET-2138 > >> > Thanx! We would need to setup tests to be sure that this won't happen. > >> > > >> > Thanx for your input, > >> > cheers, > >> > Martin > >> > > >> > > >> >> > >> >> > >> >> -Victor > >> >> > >> >> On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote: > >> >> > >> >> > You can check the TIM integration work from the Terracotta guys. That > >> >> > should make things easier, and you could even try it out, perhaps > >> >> > saving a memcached implementation completely :) > >> >> > > >> >> > Martijn > >> >> > > >> >> > On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke > >> >> > <[email protected]> wrote: > >> >> >> Hi, > >> >> >> > >> >> >> we're just thinking about a session store using memcached. I just > >> >> >> want > >> >> >> to ask if somebody already implemented this (and wants to share) > >> >> >> before > >> >> >> we implement this. > >> >> >> > >> >> >> Btw, is there some documentation about ISessionStore semantics, in > >> >> >> addition to javadocs? I would be interested in the order in which the > >> >> >> different methods would be invoked. > >> >> >> > >> >> >> Thanx && cheers, > >> >> >> Martin > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Become a Wicket expert, learn from the best: http://wicketinaction.com > >> >> > Apache Wicket 1.3.5 is released > >> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > >> >> > > >> >> > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [email protected] > >> >> > For additional commands, e-mail: [email protected] > >> >> > > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> > > >> > >> > >> > > > > >
signature.asc
Description: This is a digitally signed message part
