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
<[email protected]>wrote:
On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote:
Even if you have the memcached store in place, wicket still
requires
session affinity. Wicket buffers redirect responses locally so the
client needs to go to the same server twice or the client will
receive
an expired session. Wicket is a stateful framework, session
affinity
is a must.
Are there other things (besides the buffered response when doing a
redirect-after-post with the REDIRECT_TO_BUFFER setting) that
require
sticky sessions?
We'd like to use wicket in a stateless mode and defer session
creation
as long as it's possible for a user. Even if wicket is made with a
statefull programming model in mind we think there are still many
advantages over other (non-component-based) frameworks. Also we
need a
dynamic structure which would be rather hard to realize/simulate
with
some other component oriented frameworks ;)
Cheers,
Martin
On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote:
On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
Starts to sound like a form of premature optimization. If you
are new
to Wicket, why do you want to implement a memcached session
store?
What is the usecase?
We're starting a new project (the relaunch of a big ecommerce
system)
and want to be able to scale out (just throw in new hardware when
traffic grows). Additionally we have the requirement of session
failover, both in standard operations and for deployments.
We're discussing non-sticky vs. sticky sessions here and for non-
sticky
sessions memcached (as caching layer in addition to sessions
stored
in a
database) is a good candidate, as you don't replicate the changed
session to all other nodes, but only to the primary node for this
session id. This is an important aspect for beeing able to scale
out.
Concerning non-sticky/sticky/memcached/whatever we're not
decided yet,
still running in evaluation mode :)
Cheers,
Martin
Martijn
On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
<[email protected]> wrote:
On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
I wrote a memcached session manager store for jetty, that our
wicket
app utilizes. Works well, except I can't open source it,
since it was created on the company's dime ;-(
Well, most interesting things are not so simple to realize that
one can
do it in its spare time. But the good point is that we can do
such
interesting things in our job :)
Here is my opinion on memcached as a session store.
Memcached will not work well as a wicket session store, due
to 1mb
size limits.
Good to know, I wasn't aware of this restriction (I still need
to
read
more about this for details). So one is forced to handle
resources
eating much memory (e.g. fileupload) not via session, which is
the
case
even without this 1 mb size limit :)
Do you have a case where this limit is important especially for
wicket?
You honestly don't want to serialize anything past 100kb
in size due to performance reasons.
Right.
That said, It works best if you
use memcached as a container httpsessionstore with the wicket
secondlevelcache diskpagestore. The only thing you need to
serialize
is the last pagemap which should only be 50kb in size max. You
still
get fail over since the last page map is distributed.
And I have to read about page maps (I'm really new to wicket
as you
see :)). AFAIK page maps store a configurable numer of versioned
pages
for back-button support and versioned pages.
One thing you need to be careful with is not referencing
anything
that
got stored on disk from your active pagemap, it will spiral
into a
stack overflow.
https://issues.apache.org/jira/browse/WICKET-2138
Thanx! We would need to setup tests to be sure that this won't
happen.
Thanx for your input,
cheers,
Martin
-Victor
On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote:
You can check the TIM integration work from the Terracotta
guys.
That
should make things easier, and you could even try it out,
perhaps
saving a memcached implementation completely :)
Martijn
On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke
<[email protected]> wrote:
Hi,
we're just thinking about a session store using memcached.
I just
want
to ask if somebody already implemented this (and wants to
share)
before
we implement this.
Btw, is there some documentation about ISessionStore
semantics,
in
addition to javadocs? I would be interested in the order in
which the
different methods would be invoked.
Thanx && cheers,
Martin
--
Become a Wicket expert, learn from the best:
http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
