You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Grotzke <ma...@javakaffee.de> on 2009/03/08 23:01:33 UTC
memcached session store
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
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Wed, 2009-03-11 at 09:31 -0700, Eelco Hillenius wrote:
> > 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?
>
> Right. And there is back button support (access to older pages/
> previous renderings) to consider,
I asume you are referring to the PageMap storing versioned pages...
> which without session affinity
> you'll have to distribute throughout your cluster (though you might
> want to do that anyway to support fall over).
Right now we plan to run Wicket without a PageMap (or 0 versioned
pages), REDIRECT_TO_RENDER and only LoadableDetachableModel with all
required information in the URL. Do you think there are problems with
this approach?
Would you say REDIRECT_TO_RENDER has other disadvantages besides
fetching entities twice?
Cheers,
Martin
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: memcached session store
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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?
Right. And there is back button support (access to older pages/
previous renderings) to consider, which without session affinity
you'll have to distribute throughout your cluster (though you might
want to do that anyway to support fall over).
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> <ma...@javakaffee.de> 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
> >> <ma...@javakaffee.de> 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
> >> >> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >
> >>
> >>
> >>
> >
>
>
>
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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.
Probably you are referring to IRequestCycleSettings.renderStrategy set
to REDIRECT_TO_BUFFER. This is a good point to consider, thanx!
> If the
> buffered response is not available, it would require rendering all
> content again, requiring fetching all entities, etc. from the
> database.
I asume you are referring to the REDIRECT_TO_RENDER strategy. With this
entities have to be fetched again, but rendering only should occur once
- in the GET request following the redirect. I asume that it's possible
to reduce redirect-after-post to form submits only, right?
In respect to fetching entities twice during a redirect-after-post, we'd
try to keep the session very lightweight in either way and only store
entity ids therein, so for us this wouldn't make much difference.
Are there other things to consider when using REDIRECT_TO_RENDER in
wicket?
Cheers,
Martin
>
> Martijn
>
>
> On Mon, Mar 9, 2009 at 3:03 PM, Martin Grotzke
> <ma...@javakaffee.de> 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
> >> <ma...@javakaffee.de> 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
> >> >> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >
> >>
> >>
> >>
> >
>
>
>
Re: memcached session store
Posted by Martijn Dashorst <ma...@gmail.com>.
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
<ma...@javakaffee.de> 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
>> <ma...@javakaffee.de> 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
>> >> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >
>>
>>
>>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Johan Compagner <jc...@gmail.com>.
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
<ma...@javakaffee.de>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
> > >> <ma...@javakaffee.de>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
> > >>>>>> <ma...@javakaffee.de> 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
> > >>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>
> > >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> >> <ma...@javakaffee.de>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
> >>>>>> <ma...@javakaffee.de> 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
> >>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: memcached session store
Posted by Victor Igumnov <vi...@fabulously40.com>.
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.
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.
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
>> <ma...@javakaffee.de>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
>>>>>> <ma...@javakaffee.de> 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
>>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Igor Vaynberg <ig...@gmail.com>.
why would server one have 1000 users while server two and three are empty?
do you mean that in the time between user starting a heavy task and
your loadbalancer receiving a cpu-load update from server one it has
already received 1000 new requests from 1000 users while server two
and three have not received any?
while roundrobin allows you to *more* evenly distribute the load,
sticky sessions do a pretty good job as well. further, you should not
have any heavy tasks running inside servlet threads.
as soon as you have any state roundrobin becomes inefficient because
you either have to replicate the state to all other nodes or to a
central resource like a db.
with stickysessions you simply have a backup-buddy node and only
replicate state between those two.
so i guess what i am trying to say is: round-robin is great for
serving static content, for webapps its uselss unless your application
is completely stateless.
just my two cents, if it were up to me we wouldnt even introduce the
complexity of supporting round robin with direct render strategy.
-igor
On Fri, Mar 13, 2009 at 12:08 PM, Victor Igumnov
<vi...@fabulously40.com> wrote:
> @martin
>
> REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have
> screwed something up?
>
> @Johan
>
> The point of non-sticky sessions is to have even load distribution on your
> cluster. What happens when you have 1,000 users dependent
> on server1 that is processing some heavy background task for one of the
> users? Server2 and Server3 will sit idle.
>
> That said, in our case, a two server sticky session setup has been working
> out wonderfully. It all comes down to a decent site architecture
> that will make or break your site under load.
>
> -Victor
>
>
>
> On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote:
>
>> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
>>>
>>> thats impossible to do completely
>>> A refresh of a browser is for example 1
>>
>> Ok, from a technical/academical point of view this is valid. However,
>> GET requests should not modify any data. For POST-requests the user also
>> has to confirm that form data is resent. Also users pressing F5 (and
>> confirming resending of data) all the time are not as common as the well
>> known double-clickers...
>>
>> Did you really had issues with this? What was the setup/conditions in
>> this case?
>>
>>>
>>> And that would be quite annoying that you have to do that because you
>>> have
>>> some kind of configuration on the serverside
>>
>> What do you want to say with this? I don't understand this.
>>
>> Cheers,
>> Martin
>>
>>
>>>
>>> johan
>>>
>>>
>>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
>>> <ma...@javakaffee.de>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
>>>>> <ma...@javakaffee.de>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
>>>>>>>>> <ma...@javakaffee.de> 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
>>>>>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Johan Compagner <jc...@gmail.com>.
like igor already also stated but just want to stress this out a bit more
If you are really in the big numbers then round robin dividing sticky
sessions will be just as good as just round robin
I cant believe that there is any difference, its all about statistics
for example you have 3 servers and you get 900 new sessions that are round
robin divided when started.
then the 3 servers have 300 sessions each..
Then if from those 900 sessions 300 session are logged off What do you think
the division will be?
My big guess is that all the server are still pretty even and all of them
are around 200 (+/- a few)
If now of those 600 sessions that are left, 30 of them are really heavy
users with some big stuff
what is the change that they are all on 1 server? 0% if you ask me
Again i think that heavy sessions are evenly divided over the 3 servers So
+/- 10 on each.
Its just statistics, how bigger the numbers are how closer they will evenly
divide over all your servers.
Besides that if you use round robin request, does your load balancer really
look at the server which is now doing the most?
(then it is not round robin ofcourse) Because only then you can somehow
really divide it.
But i think this is pretty tricky, because what is heavy use at 1 point in
time
So saying that none sticky sessions dont balance that well is just not true,
i think they will balance just as good and that balance will be even more
balanced when the numbers are getting higher.
johan
On Fri, Mar 13, 2009 at 20:08, Victor Igumnov <vi...@fabulously40.com>wrote:
> @martin
>
> REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have
> screwed something up?
>
> @Johan
>
> The point of non-sticky sessions is to have even load distribution on your
> cluster. What happens when you have 1,000 users dependent
> on server1 that is processing some heavy background task for one of the
> users? Server2 and Server3 will sit idle.
>
> That said, in our case, a two server sticky session setup has been working
> out wonderfully. It all comes down to a decent site architecture
> that will make or break your site under load.
>
> -Victor
>
>
>
>
> On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote:
>
> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
>>
>>> thats impossible to do completely
>>> A refresh of a browser is for example 1
>>>
>> Ok, from a technical/academical point of view this is valid. However,
>> GET requests should not modify any data. For POST-requests the user also
>> has to confirm that form data is resent. Also users pressing F5 (and
>> confirming resending of data) all the time are not as common as the well
>> known double-clickers...
>>
>> Did you really had issues with this? What was the setup/conditions in
>> this case?
>>
>>
>>> And that would be quite annoying that you have to do that because you
>>> have
>>> some kind of configuration on the serverside
>>>
>> What do you want to say with this? I don't understand this.
>>
>> Cheers,
>> Martin
>>
>>
>>
>>> johan
>>>
>>>
>>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
>>> <ma...@javakaffee.de>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
>>>>> <ma...@javakaffee.de>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
>>>>>>>>> <ma...@javakaffee.de> 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
>>>>>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: memcached session store
Posted by Victor Igumnov <vi...@fabulously40.com>.
@martin
REDIRECT_TO_RENDER did not work in my case as well. Possibly I might
have screwed something up?
@Johan
The point of non-sticky sessions is to have even load distribution on
your cluster. What happens when you have 1,000 users dependent
on server1 that is processing some heavy background task for one of
the users? Server2 and Server3 will sit idle.
That said, in our case, a two server sticky session setup has been
working out wonderfully. It all comes down to a decent site architecture
that will make or break your site under load.
-Victor
On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote:
> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
>> thats impossible to do completely
>> A refresh of a browser is for example 1
> Ok, from a technical/academical point of view this is valid. However,
> GET requests should not modify any data. For POST-requests the user
> also
> has to confirm that form data is resent. Also users pressing F5 (and
> confirming resending of data) all the time are not as common as the
> well
> known double-clickers...
>
> Did you really had issues with this? What was the setup/conditions in
> this case?
>
>>
>> And that would be quite annoying that you have to do that because
>> you have
>> some kind of configuration on the serverside
> What do you want to say with this? I don't understand this.
>
> Cheers,
> Martin
>
>
>>
>> johan
>>
>>
>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
>> <ma...@javakaffee.de>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
>>>> <ma...@javakaffee.de>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
>>>>>>>> <ma...@javakaffee.de> 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
>>>>>>>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>>>> help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Johan Compagner <jc...@gmail.com>.
a get request will change the page.
For example wicket always tries to redirect to the page.
So that a post will always be a normal get to the current page. (so no
resend of post data when pressing F5)
But the page that you render can change. For example you can show a listview
on that table
and some rows are changed because others did do an update on that database
data
Then the component structure of the page will be changed.
So it is not about resending data or do an action again on F5, no it is just
getting the latest data from the server.
Back to the none sticky sessions:
A use clicks on the page (that is a listview with 5 rows) on a link or
button
That takes a lot of time. So a user does a refresh of that same page
That goes to another server then the button click request which is still
going on.
That last request is fast and returns the same listview of 5 rows.
So the page is now in sync with what the user sees.
Then the first request goes on and alters the page and now on that point
there where only 4 rows left
(and i guess now the containter will overwrite this page with the page the
user is currently showing in the browser)
Then if a user clicks on row 5.. That element isnt there anymore...
On Fri, Mar 13, 2009 at 11:58, Martin Grotzke
<ma...@javakaffee.de>wrote:
> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
> > thats impossible to do completely
> > A refresh of a browser is for example 1
> Ok, from a technical/academical point of view this is valid. However,
> GET requests should not modify any data. For POST-requests the user also
> has to confirm that form data is resent. Also users pressing F5 (and
> confirming resending of data) all the time are not as common as the well
> known double-clickers...
>
> Did you really had issues with this? What was the setup/conditions in
> this case?
>
> >
> > And that would be quite annoying that you have to do that because you
> have
> > some kind of configuration on the serverside
> What do you want to say with this? I don't understand this.
>
> Cheers,
> Martin
>
>
> >
> > johan
> >
> >
> > On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
> > <ma...@javakaffee.de>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
> > > > <ma...@javakaffee.de>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
> > > > > > >> <ma...@javakaffee.de> 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
> > > > > > >>>>> <ma...@javakaffee.de> 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:
> users-unsubscribe@wicket.apache.org
> > > > > > >>>>> For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > >
> ---------------------------------------------------------------------
> > > > > > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > >>>> For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > >
> > >
>
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
> thats impossible to do completely
> A refresh of a browser is for example 1
Ok, from a technical/academical point of view this is valid. However,
GET requests should not modify any data. For POST-requests the user also
has to confirm that form data is resent. Also users pressing F5 (and
confirming resending of data) all the time are not as common as the well
known double-clickers...
Did you really had issues with this? What was the setup/conditions in
this case?
>
> And that would be quite annoying that you have to do that because you have
> some kind of configuration on the serverside
What do you want to say with this? I don't understand this.
Cheers,
Martin
>
> johan
>
>
> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
> <ma...@javakaffee.de>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
> > > <ma...@javakaffee.de>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
> > > > > >> <ma...@javakaffee.de> 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
> > > > > >>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > > > > >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > >
> >
Re: memcached session store
Posted by Johan Compagner <jc...@gmail.com>.
thats impossible to do completely
A refresh of a browser is for example 1
And that would be quite annoying that you have to do that because you have
some kind of configuration on the serverside
johan
On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
<ma...@javakaffee.de>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
> > <ma...@javakaffee.de>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
> > > > >> <ma...@javakaffee.de> 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
> > > > >>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > > > >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > >
>
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> <ma...@javakaffee.de>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
> > > >> <ma...@javakaffee.de> 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
> > > >>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > > >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
Re: memcached session store
Posted by Johan Compagner <jc...@gmail.com>.
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
<ma...@javakaffee.de>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
> > >> <ma...@javakaffee.de> 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
> > >>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> >> <ma...@javakaffee.de> 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
> >>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: memcached session store
Posted by Victor Igumnov <vi...@fabulously40.com>.
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.
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
>> <ma...@javakaffee.de> 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
>>>>> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> <ma...@javakaffee.de> 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
> >> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
>
>
>
Re: memcached session store
Posted by Martijn Dashorst <ma...@gmail.com>.
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?
Martijn
On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
<ma...@javakaffee.de> 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
>> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
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
> > <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: memcached session store
Posted by Victor Igumnov <vi...@fabulously40.com>.
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 ;-(
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. You honestly don't want to serialize anything past 100kb
in size due to performance reasons. 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.
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
-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
> <ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: memcached session store
Posted by Martin Grotzke <ma...@javakaffee.de>.
Hi,
sounds interesting. What would you say are the advantages of terracotta
over memcached? I'd say in terms of scalability terracotty has the same
disadvantages like local (in-jvm) caches - replication has to be done to
all other nodes.
Thanx for your thoughts,
cheers,
Martin
On Sun, 2009-03-08 at 23:25 +0100, 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
> <ma...@javakaffee.de> 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
> >
> >
>
>
>
Re: memcached session store
Posted by Martijn Dashorst <ma...@gmail.com>.
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
<ma...@javakaffee.de> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org