In my point of view none sticky sessions are just broken or can be broken very easily I dont know exactly how all the implementations work but does this example all ways work?
a user clicks on a button that button click does take some time and in the mean time a user clicks on the same or another button In a sticky session configuration this works fine. Wicket makes sure that they are synced and a page wont be altered by 2 threads at the same time\ But how does a none sticky configuration work? Will the second request go to another server? And just alter there the page state? It can do that because our sync block doesnt work then ofcourse. But if this happens, what happens after that? now the same page instance is altered on both places.. Which one takes precedence ? Because it is impossible for the container to merge the objects. So it should take 1 or the other.. So the first click that took longer then the second click will overwrite the second click page. But that now overwritten page is now shown to the user So if you then click on something that was on the page of the second click but wasnt on the page of the first click. Then you will get an page expired or something like that.. maybe somehow containers do some synching across concurrent request of 1 session (hopefully the will send them to the same server) But i dont know. Synching over servers is very expensive.. then the whole usage of having none sticky sessions is completely gone in my eyes. johan On Tue, Mar 10, 2009 at 10:49, Martin Grotzke <[email protected]>wrote: > 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] > > >
