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:
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
Valve className=org.apache.catalina.ha.tcp.ForceReplicationValve/
Valve className=org.apache.catalina.ha.tcp.ReplicationValve
filter=.*\.gif;.*\.jpg;.*\.png;.*\.js;.*\.htm;.*\.html;.*\.txt;.*\.css;/
/Cluster
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 (EnumerationString 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 martin.grot...@javakaffee.de 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
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 martin.grot...@javakaffee.de 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
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
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
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
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
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
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
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 jon.bris...@npcinternational.com 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
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
