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 <jon.bris...@npcinternational.com> 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