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
