Re: How to force session replication per request in a Tomcat 6 cluster - SOLVED
On Tue, 2010-05-04 at 16:53 +1000, Kevin Jansz wrote:
> 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.
Well, the memcached-session-manager does not require the one ("native")
memcached server, but only s.th. that speaks the memcached protocol
(there are actually several implementations/adaptions out there).
There's e.g. jmemcached (code.google.com/p/jmemcache-daemon/) which is
"a Java implementation of the daemon (server) side of the memcached
protocol" (copied from their site), which is also working great (I use
this for integration testing, really nice!) - just run it as any other
java program.
This just as a note for clarification regarding memcached protocol vs.
the actual implementation :-)
Cheers,
Martin
> 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
> > > "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
> > >
> >
> > --
> > Martin Grotzke
> > http://www.javakaffee.de/blog/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
signature.asc
Description: This is a digitally signed message part
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
> > "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
Re: How to force session replication per request in a Tomcat 6 cluster
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 > "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 > -- Martin Grotzke http://www.javakaffee.de/blog/ signature.asc Description: This is a digitally signed message part
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 {
>> 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. Ju
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
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
Re: How to force session replication per request in a Tomcat 6 cluster
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
