On Tue, Feb 15, 2011 at 6:01 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > On the other hand, it's very difficult for a container to determine what > the definition of "changed" is. For instance, an object may return a > different value for a method call depending on the current date and > time, yet the internal state of the object hasn't actually changed. If behaviour does not depend on internal state then the session does not need to be replicated, as the behaviour will be the same on different jvms with the same date/time.
> If Tomcat simply called all the method that return values, remembered them > all, then did a comparison at the end of every request, you'd end up > with a whole bunch of needless replication messages flying around your > cluster. Also, remembering all those return values (and, potentially all > the return values of sub-objects) would roughly double the size of every > session. I agree, not a good idea. > > Another technique might be to serialize an object and check against > /that/ after every request. This also doubles the size of every session. > > I suppose md5(serialize(object)) could work without doubling the size of > the objects. 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.). 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. 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. 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 http://code.google.com/p/kryo/ and https://github.com/eishay/jvm-serializers/wiki). - average (serialized) session size is between 10kB and 100kB - session serialization/replication is done asynchronously (not in the request thread) - overhead for msm in the request thread is ~1msec - average session serialization time is s.th. 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. > > Containers probably choose not to implement anything like the above > because the semantics of a web application's objects are simply opaque > to the container and it doesn't make any sense to even try. It's simple > enough to trigger a replication event by doing: > > session.setAttribute(key, session.getAttribute(key)); I agree, this is a very simple way to trigger replication. 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. 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. > 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. Cheers, Martin > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1asX4ACgkQ9CaO5/Lv0PDaEwCZAX1Rm4r5Xi1OZE9tXozuYnnb > 8cwAnRwg67yL9qjG2Zbwi6kryoD7XcX1 > =c4Pg > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Martin Grotzke http://www.javakaffee.de/blog/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
