From martin.grotzke on May 17, 2009 23:41:53

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=12

From [email protected] on May 08, 2009 16:35:26

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).

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=4

From martin.grotzke on March 17, 2010 00:25:02

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=48

From martin.grotzke on February 27, 2010 15:16:20

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=43

From [email protected] on February 05, 2010 12:09:15

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

Attachment: honor_xml_serializable.patch

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=33

Currently the memcached nodes are identified by the index how they are configured, this shall be changed so that provided ids are used.

Right now the user has to configure the exactly same memcached nodes in each tomcat, like this:
memcachedNodes="localhost:11211 localhost:11212"
Additionally one can specify the activeNodeIndex="0" which means that the first memcached node shall be preferred.

This shall be changed, so that sessions can be spread/balanced over (nearly) all memcached nodes. For this the user configures the memcached nodes together with an id: memcachedNodes="n1:localhost:11211 n2:localhost:11212 n2:localhost:11213"

As some memcached nodes (e.g. the one on the same machine as the tomcat is running on) shall only be used for session backup if all other memcached nodes died, the user can specify failoverNodes="n1".

From [email protected] on June 05, 2009 00:37:56

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!

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=14

From martin.grotzke on October 25, 2009 01:27:54

The sessionBackupAsync switch is implemented but not documented...

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=23

From martin.grotzke on February 16, 2010 23:41:32

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 -
  https://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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=36

From martin.grotzke on March 19, 2009 22:53:28

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=1

From martin.grotzke on May 10, 2009 01:37:43

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=10

From [email protected] on February 23, 2010 10:19:28

From context.xml:

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=40

From martin.grotzke on October 18, 2009 00:44:35

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=16

From martin.grotzke on May 10, 2009 01:18:25

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=7

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.

From martin.grotzke on October 25, 2009 01:26:22

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=22

From [email protected] on March 08, 2010 08:50:09

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 !

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=45

From martin.grotzke on January 04, 2010 00:16:26

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)

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=28

From [email protected] on May 08, 2009 16:43:12

_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]

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=5

From martin.grotzke on May 10, 2009 01:32:58

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=9

From [email protected] on February 10, 2010 12:13:00

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

Attachment: 0002-added-special-XMLFormat-for-java.util.Currency.patch

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=34

From martin.grotzke on January 04, 2010 01:49:52

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)

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=31

From [email protected] on March 05, 2010 14:06:59

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=44

From martin.grotzke on December 29, 2009 22:48:32

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=26

From martin.grotzke on October 19, 2009 01:23:57

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=17

From martin.grotzke on October 24, 2009 22:04:58

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=18

From martin.grotzke on October 25, 2009 01:23:59

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=21

From martin.grotzke on January 04, 2010 01:34:17

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)

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=30

From martin.grotzke on May 10, 2009 00:19:19

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=6

From martin.grotzke on May 10, 2009 01:26:10

If session backup shall be performed asynchronously shall be configurable.

Also this option needs tests.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=8

From martin.grotzke on October 25, 2009 01:29:26

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=24

From martin.grotzke on May 12, 2009 01:05:35

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 );

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=11

From martin.grotzke on October 25, 2009 01:21:36

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]

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=19

From martin.grotzke on October 25, 2009 01:22:56

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=20

From [email protected] on February 16, 2010 02:55:25

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=35

From martin.grotzke on February 19, 2010 15:04:37

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=37

From martin.grotzke on March 15, 2010 00:18:26

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=46

From martin.grotzke on March 16, 2010 23:05:14

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).

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=47

From martin.grotzke on February 24, 2010 16:14:06

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=41

From martin.grotzke on April 10, 2009 23:39:21

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=2

From martin.grotzke on May 18, 2009 00:08:11

can we use markup?

How does this look?

What about

paragraphs?

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=13

From martin.grotzke on September 02, 2009 01:14:30

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=15

From martin.grotzke on April 26, 2009 00:24:50

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]+)?

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=3

From martin.grotzke on January 02, 2010 15:13:03

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.(XMLFormat.java:182)
at
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat$XMLNumberForma
t.(ReflectionFormat.java:591)
at
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat$XMLNumberIntFo
rmat.(ReflectionFormat.java:662)
at
de.javakaffee.web.msm.serializer.javolution.ReflectionFormat.createNumberFo
rmat(ReflectionFormat.java:569)

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=27

From martin.grotzke on November 22, 2009 00:16:48

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

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=25

From martin.grotzke on February 22, 2010 21:25:10

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=39

From martin.grotzke on January 04, 2010 00:59:59

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)

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=29

From martin.grotzke on February 24, 2010 16:25:31

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.?

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=42

From martin.grotzke on January 05, 2010 08:57:40

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">






<iZone

class="org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone"
__id="29" iID="Europe/Berlin">

<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" />


<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...

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=32

From martin.grotzke on February 19, 2010 15:07:39

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.

Original issue: http://code.google.com/p/memcached-session-manager/issues/detail?id=38