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] >
signature.asc
Description: This is a digitally signed message part
