Re: How to force session replication per request in a Tomcat 6 cluster - SOLVED
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: 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 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 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 &g
Re: How to force session replication per request in a Tomcat 6 cluster
Out of curiosity I tried the SimpleTcpReplicationManager with the useDirtyFlag="false" and it definitely does not work 30/04/2010 10:12:37 AM org.apache.catalina.ha.tcp.SimpleTcpCluster createManager SEVERE: Unable to clone cluster manager, defaulting to org.apache.catalina.ha.session.DeltaManager java.lang.UnsupportedOperationException at org.apache.catalina.ha.session.SimpleTcpReplicationManager.cloneFromTemplate(SimpleTcpReplicationManager.java :682) at org.apache.catalina.ha.tcp.SimpleTcpCluster.createManager(SimpleTcpCluster.java:508) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4384) ... SimpleTcpReplicationManager explicitly throws UnsupportedOperationException. It's interesting that this has been reported as bug before: https://issues.apache.org/bugzilla/show_bug.cgi?id=45382 https://issues.apache.org/bugzilla/show_bug.cgi?id=45381 both marked as invalid, from what I gather because the DeltaManager should be used ... but there's no manager option for if you wanted forced replication. I tried out the Valve approach as described by Jon. The changes required were to ensure: 1. implement ClusterValve otherwise the Cluster will ignore it. 2. check the implementation of the session before casting So this was the config I tried (calling the valve "ForceReplicationValve"): It doesn't work as the sessions are instances of org.apache.catalina.ha.session.DeltaSession if the DeltaManager is used. org.apache.catalina.ha.session.ReplicatedSession is only the implementation SimpleTcpReplicationManager but as mentioned above this can't be used. So there's no way for a ClusterValve to tell the manager that the session is "dirty" and needs replication. Having just a Delta & Backup manager seems like a gap in the basic clustering offering. It does seem like the only alternative is write our own manager as Jon as done (based on SimpleTcpReplicationManager which should probably be deprecated given the UnsupportedOperationException). Perhaps this is a question for the dev list? cheers, 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 Test drive our software online - www.exari.com/demo-trial.html Read our blog on document assembly - blog.exari.com On 29 April 2010 16:41, Kevin Jansz wrote: > that's brilliant, thank you ... I have a bit more confidence in trying > this out if the custom code is so minimal. It does look like all we > require & if it plugs into the default (delta?) manager from tomcat > too that'd be great. I'll let you know how we get on ... > > I would be interested to know if anyone had comments from a more > "philosophical" point of view - is it wrong/bad-practice to put > mutable objects in the session? > > thanks again Jon. > > 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 > > > On 29 April 2010 01:36, Jon Brisbin wrote: >> >> >> On Apr 28, 2010, at 9:57 AM, Kevin Jansz wrote: >> >> > That is useful to know ... is the Valve in a state that it can be >> > shared? Did you base any of the interaction with the manager/store on >> > the SimpleTcpReplicationManager? >> >> I actually use my own, from-scratch session replication manager. It's still >> alpha, but it uses RabbitMQ to replicate sessions (I'm adding ZooKeeper into >> the mix right now, as well, to coordinate session updates). The Valve is >> responsible for calling a method I added to my Store called >> "replicateSession" after the request is processed. This sounds like it's >> similar in functionality to what you're after. >> >> I just perused the guts of SimpleTcpReplicationManager and it looks like you >> could force a replication event by setting isDirty to true in the Valve, >> after the request is processed (this is untested pseudo-code, BTW): >> >> public class ReplicationValve extends ValveBase { >> >> protected static final String info = "ReplicationValve/1.0"; >> >> �...@override >> public String getInfo() { >> return info; >> } >> >> �...@override >> public void invoke( Request request, Response response ) throws >> IOException, ServletException { >> >> getNext().invoke( request, response ); >> >> Session session = null; >> try { >> ses
Re: How to force session replication per request in a Tomcat 6 cluster
that's brilliant, thank you ... I have a bit more confidence in trying this out if the custom code is so minimal. It does look like all we require & if it plugs into the default (delta?) manager from tomcat too that'd be great. I'll let you know how we get on ... I would be interested to know if anyone had comments from a more "philosophical" point of view - is it wrong/bad-practice to put mutable objects in the session? thanks again Jon. 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 On 29 April 2010 01:36, Jon Brisbin wrote: > > > On Apr 28, 2010, at 9:57 AM, Kevin Jansz wrote: > > > That is useful to know ... is the Valve in a state that it can be > > shared? Did you base any of the interaction with the manager/store on > > the SimpleTcpReplicationManager? > > I actually use my own, from-scratch session replication manager. It's still > alpha, but it uses RabbitMQ to replicate sessions (I'm adding ZooKeeper into > the mix right now, as well, to coordinate session updates). The Valve is > responsible for calling a method I added to my Store called > "replicateSession" after the request is processed. This sounds like it's > similar in functionality to what you're after. > > I just perused the guts of SimpleTcpReplicationManager and it looks like you > could force a replication event by setting isDirty to true in the Valve, > after the request is processed (this is untested pseudo-code, BTW): > > public class ReplicationValve extends ValveBase { > > protected static final String info = "ReplicationValve/1.0"; > > �...@override > public String getInfo() { > return info; > } > > �...@override > public void invoke( Request request, Response response ) throws IOException, > ServletException { > > getNext().invoke( request, response ); > > Session session = null; > try { > session = request.getSessionInternal(); > } catch ( Throwable t ) { > // IGNORED > } > if ( null != session ) { > ((ReplicatedSession)session).setIsDirty(true); > } > } > } > > > I guess the dilemma for us is the > > org.apache.catalina.ha.session.SimpleTcpReplicationManager seems to > > have the functionality we require (ie from Tomcat 5.0) and there isn't > > anything much more we need above that. Just not sure if users are > > advised against using it for session replication. If so then I guess > > writing your own does sound like the only alternative but that does > > seem unusual when tomcat used to have replication "ignoring deltas" > > before and other app servers (I can actually only speak of websphere) > > seem to let you do this. Would the rationale be that you should only > > put immutable objects in the session and tomcat is trying to direct > > users to best practice? > > I got to the point where, in my private, hybrid cloud environment, there > aren't best practices, so I had to just do it myself. > > Jon Brisbin > Portal Webmaster > NPC International, Inc. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to force session replication per request in a Tomcat 6 cluster
That is useful to know ... is the Valve in a state that it can be shared? Did you base any of the interaction with the manager/store on the SimpleTcpReplicationManager? I guess the dilemma for us is the org.apache.catalina.ha.session.SimpleTcpReplicationManager seems to have the functionality we require (ie from Tomcat 5.0) and there isn't anything much more we need above that. Just not sure if users are advised against using it for session replication. If so then I guess writing your own does sound like the only alternative but that does seem unusual when tomcat used to have replication "ignoring deltas" before and other app servers (I can actually only speak of websphere) seem to let you do this. Would the rationale be that you should only put immutable objects in the session and tomcat is trying to direct users to best practice? -- 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 28 April 2010 22:59, Jon Brisbin wrote: > > I don't know if this really answers your question or not, but I have written > a custom Valve that calls my own replicateSession method. You could do > something similar in maybe 10 minutes to call the requisite methods on the > session Manager/Store. > > Jon Brisbin > Portal Webmaster > NPC International, Inc. > > > > On Apr 28, 2010, at 7:34 AM, 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 > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to force session replication per request in a Tomcat 6 cluster
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