On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > Even if you have the memcached store in place, wicket still requires > session affinity. Wicket buffers redirect responses locally so the > client needs to go to the same server twice or the client will receive > an expired session. Wicket is a stateful framework, session affinity > is a must. Are there other things (besides the buffered response when doing a redirect-after-post with the REDIRECT_TO_BUFFER setting) that require sticky sessions?
We'd like to use wicket in a stateless mode and defer session creation as long as it's possible for a user. Even if wicket is made with a statefull programming model in mind we think there are still many advantages over other (non-component-based) frameworks. Also we need a dynamic structure which would be rather hard to realize/simulate with some other component oriented frameworks ;) Cheers, Martin > > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke 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] > >>>> > >>> > >> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
signature.asc
Description: This is a digitally signed message part
