If you do have a lot of stateless pages then for those it doesnt matter what kind of sessions you use.
The issues he is describing do map exactly on what i am saying. Why would you have none sticky sessions? What do you think you will gain? On Fri, Mar 13, 2009 at 12:14, Martin Grotzke <[email protected]>wrote: > On Wed, 2009-03-11 at 12:06 -0700, Victor Igumnov wrote: > > I had issues when running non-sticky sessions with ONE_PASS_RENDERER, > > the results were mixed. Responses came back as a mixed bag, sometimes > > it worked or not. Expired sessions did happen from time to time with > > no rhyme or reason. Sticky sessions is a must on wicket. > Hmm, this does not improve confidence - at least not in the > implementation/handling of ONE_PASS_RENDERER. Did you address this issue > somehow on the users/dev mailing list or via the issue tracker? Also I > would cross the fingers that REDIRECT_TO_RENDER does not produce the > same issues. > > > > > I hate to say this but, if your writing a stateless oriented site, > > wicket might not be the best choice. Your fighting an uphill battle. > Our goal is to defer session creation as long as it's possible - > probably this is until the user submits the first form. With this we > asume we don't need any PageMap (0 versioned pages). > > Provided we use sticky sessions and REDIRECT_TO_BUFFER, would you say > there will be problems with this approach (statelessness as long as it's > possible and no pagemaps)? > > Thanx && cheers, > Martin > > > > > > On Mar 11, 2009, at 10:17 AM, Martin Grotzke wrote: > > > > > Hi, > > > > > > One would need to handle this on the client side, by disabling > > > buttons/links when they are clicked. Also AJAX communicatoin has to be > > > handled, as this is also often a candidate that triggers multiple > > > requests running in parallel. > > > > > > Cheers, > > > Martin > > > > > > > > > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > > >> 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] > > >>>> > > >>> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > >
