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
<martin.grot...@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
<martin.grot...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
