On Tue, 2010-05-04 at 16:53 +1000, Kevin Jansz wrote:
> PS thanks for the responses. Martin, the session manager project
> sounds awesome but the use of memcached (c-based native code server if
> I read correctly) would make it a non-starter for us. The future use
> of ehcache sounds promising, but I'd consider this (and Terracotta
> too) only for the most critical deployments.
Well, the memcached-session-manager does not require the one ("native")
memcached server, but only s.th. that speaks the memcached protocol
(there are actually several implementations/adaptions out there).
There's e.g. jmemcached (code.google.com/p/jmemcache-daemon/) which is
"a Java implementation of the daemon (server) side of the memcached
protocol" (copied from their site), which is also working great (I use
this for integration testing, really nice!) - just run it as any other
java program.This just as a note for clarification regarding memcached protocol vs. the actual implementation :-) Cheers, Martin > Sure the > broadcast-to-all-over-tcp approach above is not going to scale well > for up to dozens of nodes but is good enough for a couple of nodes in > a basic cluster - I believe we're yet to have tomcat instance go down > in the clusters we've been involved in setting up. > > > -- > Kevin Jansz > kevin.ja...@exari.com > Level 7, 10-16 Queen Street, Melbourne 3000 Australia > Tel +61 3 9621 2773 | Fax +61 3 9621 2776 > Exari Systems > Boston | London | Melbourne | Munich > www.exari.com > > Test drive our software online - www.exari.com/demo-trial.html > Read our blog on document assembly - blog.exari.com > > > > On 2 May 2010 07:21, Martin Grotzke <martin.grot...@javakaffee.de> wrote: > > > > Hi, > > > > I created the memcached-session-manager as an alternative session > > replication solution: > > code.google.com/p/memcached-session-manager/ > > > > It keeps sessions in local memory and stores session additionally in > > memcached nodes (for backup, asynchronously if desired). > > Sessions are replicated when session data has changed, so that no > > setAttribute is required. > > > > There are also different serialization stategies available, additionally > > to default java serialization there's a javolution/xml based one, and I > > also just added serialization based on kryo [1] (very fast according to > > protobuf-thrift-compare benchmark). Both (javolution, kryo based) don't > > need objects in the session attributes object graph to implement > > Serializable - which is sometimes useful, e.g. if "legacy" projects > > shall get session failover. > > > > Cheers, > > Martin > > > > [1] code.google.com/p/kryo/ > > > > > > On Wed, 2010-04-28 at 22:34 +1000, Kevin Jansz wrote: > > > In a Tomcat 6 cluster can you force session replication on every > > > request? In Tomcat 5.0.x you had the ability to set > > > useDirtyFlag="false" on the manager > > > (org.apache.catalina.cluster.session.SimpleTcpReplicationManager) - > > > meaning a mutable object in the session would always be > > > "re-replicated". > > > > > > Looking at the source I can see the old "SimpleTcpReplicationManager" > > > manager implementation in the new "org.apache.catalina.ha.session" > > > package - and it still has the useDirtyFlag but the javadoc comments > > > in this state it's "Tomcat Session Replication for Tomcat 4.0" ... I > > > don't know if this is ok to use - I'm guessing not as it's not > > > mentioned in the main cluster configuration documentation. > > > > > > aside: a similar question was posed on stackoverflow (with more detail > > > and formatting) with no response: > > > http://stackoverflow.com/questions/2680958 - I'd be happy with > > > comments in either forum, and I'll share the advice. > > > > > > Regards, > > > Kevin > > > > > > -- > > > Kevin Jansz > > > kevin.ja...@exari.com > > > Level 7, 10-16 Queen Street, Melbourne 3000 Australia > > > Tel +61 3 9621 2773 | Fax +61 3 9621 2776 > > > Exari Systems > > > Boston | London | Melbourne | Munich > > > www.exari.com > > > > > > --------------------------------------------------------------------- > > > 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 >
signature.asc
Description: This is a digitally signed message part
