Out of curiosity I tried the SimpleTcpReplicationManager with the
useDirtyFlag="false" and it definitely does not work
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Manager
className="org.apache.catalina.ha.session.SimpleTcpReplicationManager"
expireSessionsOnShutdown="false"
useDirtyFlag="false"
notifyListenersOnReplication="true"/>
</Cluster>
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"):
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Valve className="org.apache.catalina.ha.tcp.ForceReplicationValve"/>
</Cluster>
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 <kevin.ja...@exari.com> 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 <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
