@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
<[email protected]>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: users-
[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]
