escapecycle / memcached-session-manager Goto Github PK

When a session was relocated it seems to be not in the sessions map:
  getSession( session.getId() ) != null
is always false...

Somehow weird, as directly before the session was added via
  add( session );

As reported here [1], memcached-session-manager cannot be run with java 1.5.

This should be changed.

[1] 
http://groups.google.com/group/memcached/browse_thread/thread/b7d9aab5f8aeb7
96

msm-javolution-serializer in version 1.1 does not support deserialization 
of java.util.Collections$UnmodifiableMap, this fails with this exception:

Jan 4, 2010 1:29:34 AM 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat readElements
SEVERE: Could not set field value for field private java.util.Map 
org.app.SomeClass._someField                                                    

java.lang.UnsupportedOperationException                                         

        at java.util.Collections$UnmodifiableMap.put(Collections.java:1285)                                                 
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionBinding$XMLMapFormat.
read(ReflectionBinding.java:362)      
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionBinding$XMLMapFormat.
read(ReflectionBinding.java:329)      
        at 
javolution.xml.XMLFormat$InputElement.readInstanceOf(XMLFormat.java:507)        

        at javolution.xml.XMLFormat$InputElement.get(XMLFormat.java:403)

When a new memcached node is added or an existing one is removed the 
configuration of the memcached-session-manager needs to be updated: both the 
memcachedNodes have to be updated and perhaps also the failoverNodes.

This should be possible via jmx.

What steps will reproduce the problem?
1. Use memcached-session-manager with an application that uses Log4j.

What is the expected output? What do you see instead?
Log messages should be handled by the configured logging system, but they
are instead written to System.err stream.


What version of the product are you using? On what operating system?
1.1

Please provide any additional information below.
Tomcat uses commons logging (http://commons.apache.org/logging/) internally
which allows it to be used easily with different logging systems.
Unfortunately memcached-session-manager is hard coded to use Java Logging,
which causes some pain when the rest of the application is using other
logging mechanisms.

P.S. Thank you for this great piece of software. We are planning to use it
in our web application, which is running on a cluster of four highly loaded
web servers.

Wicket has an AbstractHttpSessionStore.SessionBindingListener class 
(implementing HttpSessionBindingListener and Serializable) that stores the 
session id. When valueUnbound is invoked by the servlet container, the 
SessionBindingListener invokes 
application.getSessionStore().unbind(sessionId) which in turn cleans up the 
PageStore (used by the SecondLevelCacheSessionStore) and the 
bufferedResponses held by the WebApplication.

The question is what does happen when a session is relocated and therefore 
the session id is changed.

Right now the session is serialized using the standard jdk serialization.

It should be possible to plug-in other serialization strategies, to support 
backward/forward compatibility of user types / classes.

Another advantage/goal might be performance improvements.

Right now sessions are sent to memcached for each request, even if the 
session was not modified by this request.

To improve performance sessions should only be sent to memcached if they 
were modified, that is they differ from the session that is already stored 
in memcached.

As the session can contain complex objects modifications of such object 
graphs cannot be detected by the memcached session manager.
To detect a modification of the data stored in the session a hash over the 
serialized session can be used: the session is stored with this hash in 
memcached (and in the tomcats session map) and when the session shall be 
sent again to memcached the hash can be computed again and compared with the 
previous hash. The hash of course must not be included in the serialized 
byte array but has to be stored separately.

One thing to consider is the expiration in memcached. Possible solutions:
- Increase the expiration significantly
- Use the (requested) touch operation to extend the expiration, 
unfortunately this is not yet possible - 
http://code.google.com/p/memcached/issues/detail?id=110
- Send the session following some algorithm even if it was not modified to 
extend the expiration (e.g. after a certain time period)
Still need to figure out what's the best solution for this.

For memcached failover we should use some kind of cache (with a short ttl,
~1 sec) to store unavailable memcached nodes. This prevents us from trying
to store sessions in unavailable nodes, or reduces the number of times this
is done.

msm-javolution-serializer in version 1.1 seems to not support 
deserialization of java.util.Collections$SynchronizedMap, this fails with:

Jan 4, 2010 12:58:17 AM 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat readElements
SEVERE: Could not set field value for field protected java.util.Map 
org.apache.catalina.session.StandardSession.attributes
javolution.xml.stream.XMLStreamException caused by 
java.lang.InstantiationException: java.util.Collections$SynchronizedMap
    at javolution.xml.XMLFormat.newInstance(XMLFormat.java:262)
    at 
javolution.xml.XMLFormat$InputElement.readInstanceOf(XMLFormat.java:499)
    at javolution.xml.XMLFormat$InputElement.get(XMLFormat.java:403)

Right now the SessionTrackerValve checks if session backup is necessary by
asking for the current session at the end of the request. If there's a
sessoin existing, the session backup must be performed.

Unfortunately, this leads to MemcachedBackupSessionManager.findSession
which performs a loadFromMemcached. This is not ideal in terms of
performance and should be changed.
E.g. the request and response cookies could be used for this.

I know of one main function which was introduced for just testing a regex.
This has to be removed, and other potential dummies as well.

Hi ! tank you for helping !
my case is that:
I have a haproxy & tomcats cluster .
the haproxy:80 works at the front of this cluster ,
and there are some tomcats work together .
  haproxy can check the healthy of the tomcats , so one or more tomcats 
die doesn't make trouble to me ,but the haproxy cannot cache the 
JsessionID, so I was wondering if there is a good way to do that ,so I 
google it , I saw your work "memcached-session-manager" project,but I 
think your high-aviliablity clusters just like heartbeat , how to add more 
tomcats  servers ? and I cant understand the configuration clearly , for 
example "where is the memcached server and howto configur it ?" and , I 
dont know how to use your idea on my situation . I hop you can give me a 
help ! thanks you very much !

The MemcachedBackupSessionManager.createSession right now does not set the 
sessionId that might be provided but creates a new one.

IIRC I did not see this case when I implemented it and therefore skipped it.

The question is, in which case this might happen and what's the value of the 
session id - e.g. is it a session id for a session that could not be loaded 
from memcached, an id for a expired session etc.?

java.util.Currency gets serialized and deserialized with the
ReflectionFormat which always creates new instances during deserialization.

The transient field defaultFractionDigits is then always zero and a
comparision with equals may return false even if the currencyCode is equal
since it is just Object.equals(). Only one instance should exist for each
currencyCode.

This applies to all Versions up to and including 1.2-SNAPSHOT.

I've added a patch that provides a special XMLFormat for Currency that
resolves the issue.

Thomas

The servlet spec #SRV.7.7.2 "Distributed Environments" says:

"Containers must notify any session attributes implementing the 
HttpSessionActivationListener during migration of a session. They must 
notify listeners of passivation prior to serialization of a session, and of 
activation after deserialization of a session."

This semantics should be supported by the msm-javolution-serializer.

Right now the msm-javolution-serializer provides some special xmlformat 
implementations for specific java types. Others are handled by the 
ReflectionFormat.

It should be checked if for some types (e.g. Locale, Currency, Pattern) 
specific xmlformat implementations would be useful.

A good idea of type candidates gives the xstream converters overview: 
http://xstream.codehaus.org/converters.html

For 1.0 there must be basic documentation: how to install and configure
this session manager.

Right now the code compiles to java 6, this should be changed to support
java 5.

As reported by Erik there's an error if all configured nodes are also set as 
failover nodes ([1]), so that no "regular" nodes are registered.

This case needs to be handled.


[1] http://groups.google.com/group/memcached-session-
manager/browse_thread/thread/3cfcc2fe58879ae4

The default transcoder (created by JavaSerializationTranscoderFactory) uses 
tomcats StandardSession to serialize/deserialize sessions and their 
attributes (writeObject/readObject).

All session attribute values that are not Serializable but implement 
HttpSessionBindingListener or HttpSessionActivationListener get their 
appropriate methods invoked (valueUnbound/attributeRemoved).

This should be documented as users need to be aware of this when starting to 
use msm.

Currently the list of nodes in the configuration is whitespace-separated. 
Due to problems in passing such lists to the tomcat in environment-
variables, an alternative format using commas as separators would be 
helpful.

What steps will reproduce the problem?
1. $CATALINA_HOME/bin/shutdown.sh
2. ps auxww | grep -i tomcat | grep -v grep
3. Tomcat is still running and the process needs to be killed manually

Our Tomcat instance did gracefully shutdown before adding memcached
session manager.

Adding '_memcached.shutdown()' in the 'stop' method in
MemcachedBackupSessionManager.java appears to resolve 
the issue:

   public void stop() throws LifecycleException {
       if ( initialized )
       {
           _memcached.shutdown();
           destroy();
       }
   }

Thanks!

-kenan

p.s.
This implementation was exactly what we were looking for to provide
high availability sessions in a clustered environment.  Really nice work!
Thanks!

When the memcached node fails a session is associated with and the session
therefore gets relocated to another memcached node, the
memcached-session-manager sets a new JSESSIONID cookie (with the session id
containing the new memcached node id).

This cookie does not have the "Secure" property set if the request was done
over a secure connection (https).

From context.xml: 

  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
             memcachedNodes="n1:server1.mydomain.com:11211 
n2:server2.mydomain.com:11211"
             failoverNodes="n1"
             transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory"
             requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
    />

Assuming that we run our app on server1, now run the webapp on server1 but 
don't run memcached on server2.

What is the expected output? What do you see instead?

Normally the app should be able to handle sessions, but it is not. Instead 
for every page a session cookie is set.

What version of the product are you using? On what operating system?

memcached-session-manager-1.1.jar, msm-javolution-serializer-1.1.jar

$ uname -a
Linux app-01 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:27:37 EST 2009 x86_64 
x86_64 x86_64 GNU/Linux

Redhat Enterprise

There's nearly everything in place so that memcached failover is fully
supported, just the relocation does not handle it fully.

So, when a backup fails, relocate() is invoked which also stores the
session in another memcached, but if this fails again, it won't be handled
correctly.

Needs to be implemented.

It would be great if one of the tomcat developers that know how session 
managers work in tomcat could review this solution and implementation.

With version 1.1 of msm-javolution-serializer a 
java.util.Collections$EmptyList cannot be deserialized. When a session is 
loaded from memcached with such an element (class attribute), this fails 
with the following exception:

Jan 4, 2010 12:11:59 AM 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat readElements
SEVERE: Could not set field value for field private final java.util.List 
org.app.SomeClass._someField                                                    

javolution.xml.stream.XMLStreamException caused by 
java.lang.IllegalAccessException: Class javolution.xml.XMLFormat can not 
access a member of class java.util.Collections$EmptyList with modifiers 
"private"                                           
        at javolution.xml.XMLFormat.newInstance(XMLFormat.java:264)                                                         
        at 
javolution.xml.XMLFormat$InputElement.readInstanceOf(XMLFormat.java:499)        

        at javolution.xml.XMLFormat$InputElement.get(XMLFormat.java:403)                                                    
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat.readElements(R
eflectionFormat.java:226)

MemcachedBackupSessionManager does not properly set the maxInactiveInterval
for sessions (it is using the default 60 seconds rather than the
sessionTimeout value from the Context).  StandardManager can be referenced
for implementation; see setContainer(Container) and
propertyChange(PropertyChangeEvent).

It should be possible to configure, if text or binary protocol shall be used 
for memcached communication.

The sessionBackupAsync switch is implemented but not documented...

can we use <em>markup</em>?

How does <code>this look</code>?

What about
<p>
paragraphs?
</p>

If a session is created when no memcached node is available (session id does 
not contain a memcached id) and afterwards a memcached node is started, such 
a session won't get bound to this memcached node (session id won't get 
changed so that it contains the memcached id).

failoverNodes right now are separated by colon (":"). To be consistent with 
the memcachedNodes attribute, they should be separated by whitespace.

Documentation also needs to reflect this.

There's a hook that intercepts the committing of the response to be able to 
send the JSESSIONID cookie with a new memcached-id to the client.

There should be tests, that show that this hook works for various scenarios, 
e.g. very small and very large responses.

The MemcachedBackupSessionManager.createSession right now does not check the 
configured maxActiveSessions and therefore does not support limiting the 
maximum number of created sessions. The implementation should follow  
org.apache.catalina.session.StandardManager.createSession.

This shouldn't be a big deal as tomcat has already jmx integration.

To prevent conflicts with the jvmRoute the sessionId format should be
changed. The jvmRoute is appended to the sessionId with a dot (".").

So the new format might be $sessionId + "-" + $memcachedId [+ "." + $jvmRoute]
which would be the following regexp: [^-.]+-[^.]+(\.[\w]+)?

A performance test that shows the difference of tomcat with and w/o the msm 
in terms of response time/throughput.

Make backup storage pluggable, so that another backend instead of memcached 
might be used, e.g. [http://ehcache.org/documentation/cache_server.html 
ehcache server]

msm-javolution-serializer in version 1.1 does not support deserialization 
of java.util.EnumSet, this fails with this exception:

Jan 4, 2010 1:47:32 AM 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat readElements
SEVERE: Could not set field value for field final java.lang.Class 
java.util.EnumSet.elementType 
javolution.xml.stream.XMLStreamException: Class null not found (see 
javolution.lang.Reflection) 
        at javolution.xml.XMLFormat$2.newInstance(XMLFormat.java:1128)                          
        at 
javolution.xml.XMLFormat$InputElement.readInstanceOf(XMLFormat.java:499)        

        at javolution.xml.XMLFormat$InputElement.get(XMLFormat.java:403)                        
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat.readElements(R
eflectionFormat.java:226)
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat.read(Reflectio
nFormat.java:205)        
        at 
javolution.xml.XMLFormat$InputElement.readInstanceOf(XMLFormat.java:507)

It might be a good idea to track the release with an issue.

Code cleanup, documentation and stuff needs to be done - is already done. 
The next version should get also release nodes.

Right now msm-javolution-serializer handles joda DateTime using reflection. 
This results in rather verbose xml. It would save space if a more efficient 
representation of joda datetime would be provided.

Right the xml for joda DateTime looks like this:

<_date class="org.joda.time.DateTime" __id="23" iMillis="1262297099473">
    <iChronology class="org.joda.time.chrono.ISOChronology"
        __id="24">
        <iBase class="org.joda.time.chrono.ZonedChronology" 
__id="25">
            <iBase class="org.joda.time.chrono.ISOChronology" 
__id="26">
                <iBase 
class="org.joda.time.chrono.GregorianChronology"
                    __id="27" iMinDaysInFirstWeek="4" 
/>
            </iBase>
            <iParam class="org.joda.time.tz.CachedDateTimeZone"
                __id="28" iID="Europe/Berlin">
                <iZone

class="org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone"
                    __id="29" iID="Europe/Berlin">
                    <iTransitions class="[J" __id="30" 
length="62">
                        <java.lang.Long value="-
9223372036854775808" />
                        <java.lang.Long value="-
2422054408000" />
                        <java.lang.Long value="-
1693706400000" />
                        <java.lang.Long value="-
1680483600000" />
                        <java.lang.Long value="-
1663455600000" />
                        <java.lang.Long value="-
1650150000000" />
                        <java.lang.Long value="-
1632006000000" />
                        <java.lang.Long value="-
1618700400000" />
                        <java.lang.Long value="-
938905200000" />
                        <java.lang.Long value="-
857257200000" />
                        <java.lang.Long value="-
844556400000" />
                        <java.lang.Long value="-
828226800000" />
                        <java.lang.Long value="-
812502000000" />
                        <java.lang.Long value="-
796777200000" />
                        <java.lang.Long value="-
781052400000" />
                        <java.lang.Long value="-
776559600000" />
                        <java.lang.Long value="-
765936000000" />
                        <java.lang.Long value="-
761180400000" />
                        <java.lang.Long value="-
748479600000" />
                        <java.lang.Long value="-
733273200000" />
                        <java.lang.Long value="-
717631200000" />
                        <java.lang.Long value="-
714610800000" />
                        <java.lang.Long value="-
710380800000" />
                        <java.lang.Long value="-
701910000000" />
                        <java.lang.Long value="-
684975600000" />
                        <java.lang.Long value="-
670460400000" />
                        <java.lang.Long value="-
654130800000" />
                        <java.lang.Long value="-
639010800000" />
                        <java.lang.Long 
value="323830800000" />
                        <java.lang.Long 
value="338950800000" />
                        <java.lang.Long 
value="354675600000" />
                        <java.lang.Long 
value="370400400000" />
                        <java.lang.Long 
value="386125200000" />
                        <java.lang.Long 
value="401850000000" />
                        <java.lang.Long 
value="417574800000" />
                        <java.lang.Long 
value="433299600000" />
                        <java.lang.Long 
value="449024400000" />
                        <java.lang.Long 
value="465354000000" />
                        <java.lang.Long 
value="481078800000" />
                        <java.lang.Long 
value="496803600000" />
                        <java.lang.Long 
value="512528400000" />
                        <java.lang.Long 
value="528253200000" />
                        <java.lang.Long 
value="543978000000" />
                        <java.lang.Long 
value="559702800000" />
                        <java.lang.Long 
value="575427600000" />
                        <java.lang.Long 
value="591152400000" />
                        <java.lang.Long 
value="606877200000" />
                        <java.lang.Long 
value="622602000000" />
                        <java.lang.Long 
value="638326800000" />
                        <java.lang.Long 
value="654656400000" />
                        <java.lang.Long 
value="670381200000" />
                        <java.lang.Long 
value="686106000000" />
                        <java.lang.Long 
value="701830800000" />
                        <java.lang.Long 
value="717555600000" />
                        <java.lang.Long 
value="733280400000" />
                        <java.lang.Long 
value="749005200000" />
                        <java.lang.Long 
value="764730000000" />
                        <java.lang.Long 
value="780454800000" />
                        <java.lang.Long 
value="796179600000" />
                        <java.lang.Long 
value="811904400000" />
                        <java.lang.Long 
value="828234000000" />
                        <java.lang.Long 
value="846378000000" />
                    </iTransitions>
                    <iWallOffsets class="[I" __id="31" 
length="62">
                        <java.lang.Integer 
value="3208000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="10800000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="10800000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="7200000" />
                        <java.lang.Integer 
value="3600000" />
                    </iWallOffsets>
                    <iStandardOffsets class="[I" 
__id="32"
                        length="62">
                        <java.lang.Integer 
value="3208000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                        <java.lang.Integer 
value="3600000" />
                    </iStandardOffsets>
                    <iNameKeys 
class="[Ljava.lang.String;" __id="33"
                        type="array" 
componentType="java.lang.String" length="62">
                        <java.lang.String __id="34" 
value="LMT" />
                        <java.lang.String __id="35" 
value="CET" />
                        <java.lang.String __id="36" 
value="CEST" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String __id="37" 
value="CEMT" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="37" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                        <java.lang.String 
__ref="36" />
                        <java.lang.String 
__ref="35" />
                    </iNameKeys>
                    <iTailZone 
class="org.joda.time.tz.DateTimeZoneBuilder$DSTZone"
                        __id="38" 
iStandardOffset="3600000" iID="Europe/Berlin">
                        <iStartRecurrence

class="org.joda.time.tz.DateTimeZoneBuilder$Recurrence"
                            __id="39" 
iNameKey="CEST" iSaveMillis="3600000">
                            <iOfYear 
class="org.joda.time.tz.DateTimeZoneBuilder$OfYear"
                                __id="40" 
iMode="u" iMonthOfYear="3" iDayOfMonth="-1"

iDayOfWeek="7" iAdvance="false" iMillisOfDay="3600000" />
                        </iStartRecurrence>
                        <iEndRecurrence

class="org.joda.time.tz.DateTimeZoneBuilder$Recurrence"
                            __id="41" 
iNameKey="CET" iSaveMillis="0">
                            <iOfYear 
class="org.joda.time.tz.DateTimeZoneBuilder$OfYear"
                                __id="42" 
iMode="u" iMonthOfYear="10" iDayOfMonth="-1"

iDayOfWeek="7" iAdvance="false" iMillisOfDay="3600000" />
                        </iEndRecurrence>
                    </iTailZone>
                </iZone>
            </iParam>
        </iBase>
    </iChronology>
</_date>

If session backup shall be performed asynchronously shall be configurable.

Also this option needs tests.

When the session contains an AtomicInteger, there's an exception thrown 
during serialization:

java.lang.IllegalArgumentException: Existing static binding for class class 
java.util.concurrent.atomic.AtomicInteger can only be overriden through 
custom XMLBinding (see XMLFormat(Class) documentation)
        at javolution.xml.XMLFormat.<init>(XMLFormat.java:182)
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat$XMLNumberForma
t.<init>(ReflectionFormat.java:591)
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat$XMLNumberIntFo
rmat.<init>(ReflectionFormat.java:662)
        at 
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat.createNumberFo
rmat(ReflectionFormat.java:569)

When the memcached node the session is associated with is not available the
session is relocated to another memcached node. This means the session id
is changed (so that it contains the new memcached node id), and the session
is internally (in the jvm local session map) bound to the new id.

To notify the browser about the new session id a new JSESSIONID cookie
(with the new session id) is sent.

When cookies are disabled this cookie is just ignored. The session id is
transported in the url via url-rewriting, and this contains still the old
session id - in more detail, the markup sent to the browser still contains
links with the old session id. Therefore the next request contains a
session id that is no longer existing - the client gets a new session.

_memcachedSessionTTL in MemcachedBackupSessionManager needs to be
configurable.  I suppose it could be a separate attribute to the Manager,
but it should probably use the same value as the session timeout
(maxInactiveInterval), no?

[XREF issue ID 4]

The java code contains wrong licence headers. Those must be changed
according to the license of this lib.

It would be great to get some stats on
- number of requests with sessions
- number of requests with sessions without access -> skipped backup
- number of requests with sessions without session modification -> skipped 
backup
- number of requests with sessions with backup
- number of sessions loaded from memcached

for each of the following there should be min, avg, max:
- serialization time
- time it took to store it in memcached (the duration of 
MemcachedClient.set)
- load time (sessions loaded from memcached)

These stats should be available via jmx

When using javolution, one can create a custom XMLFormat by use of the
XMLSerializable interface.

But this interface is ignored by the ReflectionBinding.getFormat() method.

This applies to all Versions up to and including 1.2-SNAPSHOT.

I've attached a patch that solves the issue. I've used the patch in my
project to implement a custom XMLFormat and it worked. 

Would be nice to add it to the master.

Thomas