A bit more searching on the apache bugzilla led me to this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43866
This enhancement request describes (probably a bit clearer) the gap in
functionality going from 5.0 to 5.5/6.0 - namely there's no
useDirtyFlag, so no way to tell the (more sophisticated) DeltaManager
to behave in a "dumber" way and just send everything everytime.
A comment on this enhancement request about talking directly to the
DeltaSession made me think it's worth a try - a ClusterValve has
access to this and I already had a skeleton implementation on trying
Jon's suggestion with the SimpleTcpReplicationManager. If the valve
simply grabs all the attributes and puts them back in again this is
enough for the DeltaRequest to flag the session as dirty and full
replication happens after each request.
This was the config:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Valve className="org.apache.catalina.ha.tcp.ForceReplicationValve"/>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.jpg;.*\.png;.*\.js;.*\.htm;.*\.html;.*\.txt;.*\.css;"/>
</Cluster>
the key bit of code in the ForceReplicationValve (I could share the
whole class if anyone's interested - after some clean up; better
logging; etc; etc):
@Override
public void invoke(Request request, Response response) throws
IOException, ServletException {
getNext().invoke(request, response);
Session session = null;
try {
session = request.getSessionInternal();
} catch (Throwable e) {
log.error(sm.getString("ReplicationValve.send.failure"), e);
}
if (session != null) {
if (session instanceof ReplicatedSession) {
// it's a SimpleTcpReplicationManager - can just set to dirty
((ReplicatedSession) session).setIsDirty(true);
} else {
// for everything else - cycle all attributes
List cycledNames = new LinkedList();
// in a cluster this should be
org.apache.catalina.ha.session.DeltaSession - implements HttpSession
HttpSession deltaSession = (HttpSession)session;
for (Enumeration<String> names =
deltaSession.getAttributeNames() ; names.hasMoreElements() ; ) {
String name = names.nextElement();
cycledNames.add(name);
deltaSession.setAttribute(name,
deltaSession.getAttribute(name));
}
log.debug(getInfo() + ": session " + session.getId() +
" cycled atrributes = " + cycledNames);
}
} else {
String id = request.getRequestedSessionId();
log.debug(sm.getString("ReplicationValve.session.invalid",
request.getContext().getName(), id));
}
}
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. 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
