tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Replicate session-object after values in object has been changed
Date Wed, 16 Feb 2011 16:08:34 GMT
Hash: SHA1


On 2/15/2011 3:46 PM, Martin Grotzke wrote:
> This is how it's implemented for memcached-session-manager (msm): when
> loading the session from memcached (either due to a tomcat failover or
> when loading a non-sticky session) the hash of the byte-array is
> stored. At the end of the request the session is serialized again and
> the new hash is compared with the previous one. Serialization is
> pluggable, default is java/jvm serialization, alternatives are e.g.
> kryo, which shares the same serialization semantics like java
> serialization (ignoring transient fields etc.).

Okay, so you *do* take data fingerprints. How well does that perform? I
suppose the balance of being able to replicate the objects with very
little in the way of /coding/ overhead has its advantaged, but that
seems like a lot of work to do after every request just to see if
replication is necessary.

> For msm by default a session would get replicated if at least one
> attribute was accessed (via getAttribute), so I see this change
> detection (or detection that state has not changed) as some kind of
> optimization to reduce I/O and network traffic.

Do you re-replicate the entire session or just the object that was
accessed? Or, are you saying that you only re-fingerprint the objects
that are accessed during a particular request?

> It would be really easy to disable this automatic change detection via
> configuration btw.
>> All of these techniques will kill performance. :(
> Well, what does this mean? IMHO such statements are not really useful.

Serializing objects after a request is complete delays the return of the
request processing thread to the thread pool. More threads will be
required to handle a particular user load and performance across the
webapp will suffer. Is that more specific and useful? My assertion is
that object changes are more easily detectable (or, better yet,
/knowable/) by the webapp itself and it's trivial to notify the
replication manager that an object needs to be re-replicated using

> I can share some facts + numbers (out of my head):
> - for one of the largest german ecommerce sites we use msm for session
> replication/failover
> - wicket is used as web framework, wicket stores entire pagemap
> (pages/component trees) in the session (for stateful pages)
> - kryo is used as serialization mechanism (see
> and
> - average (serialized) session size is between 10kB and 100kB
> - session serialization/replication is done asynchronously (not in the
> request thread)

That's interesting. Is there one thread that manages all replication?
Under load, does it ever fall behind? I can imagine a work queue getting
longer with each request...

> - overhead for msm in the request thread is ~1msec
> - average session serialization time is between 1msec and 10msec
> - ~20 requests per second are served by each tomcat instance
> In conclusion there's not a real impact on user experience. Most of
> the cpu time is used by the application, the overhead for
> serialization/replication is very low.

I would think this would be very application-specific: of course a light
session or trivially-serialized session-stored objects will not incur
much of a penalty.

> Although, it has an impact on your application, as either you'll
> always trigger replication, or in several places in your software you
> need to know if you change session state and you have to decide if you
> need to set the appropriate session attribute. Even more, you need to
> know which session attribute you need to set again.

My argument is that the webapp knows it's own business :)

> Some modern web frameworks try to provide a higher level of
> abstraction so that you don't get in touch with servlet stuff. If you
> need to trigger session replication via setAttribute in your
> application you need to know about internals of the web framework,
> which also might change. That was also my motivation to provide a
> transparent session change detection.

That's a fair point.

>> I am very interested in how the memcache folks accomplish this. Martin:
>> is this done via careful configuration of what "changed" means or is
>> everything automatic?
> I hope I could clarify how it's done for msm.

Thanks for the details.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message