tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Jansz <kevin.ja...@exari.com>
Subject Re: How to force session replication per request in a Tomcat 6 cluster
Date Thu, 29 Apr 2010 06:41:46 GMT
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.jansz@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.brisbin@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message