[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: [EXT]Re: Tomcat 10 session replication fails
From:       "Jonathan S. Fisher" <exabrial () gmail ! com>
Date:       2024-04-13 22:27:33
Message-ID: CAJAC5ui7oO87oPhpov6akSPr=rpSuv6jQvSkdGVpTN481TrXew () mail ! gmail ! com
[Download RAW message or body]

Sort of off topic, but sort of related. If you're having tremendous
trouble using the built in replication methods, we built a redis based
session manager: https://github.com/exabrial/redex-sm

Currently redex-sm only works with Tomcat 8.5, but it wouldn't be a
big leap to make it work with Tomcat 10. The advantage of using Redis
to store your sessions is it's a well trodden path to set up a
replicated Redis cluster, you have a lot of tooling around exploring
sessions stored inside there, and you can store hundreds-of-thousands
of sessions, or even set them to absurd timeouts (weeks).

I hate to see people struggle with session replication, as I think it
really is the secret to making server-side-rendering scale out.


On Sat, Apr 13, 2024 at 3:01 PM Chuck Caldarale <n828cl@gmail.com> wrote:
> 
> 
> > On Apr 11, 2024, at 09:07, Rick Noel <RNoel@westwoodone.com.INVALID> wrote:
> > 
> > We are getting closer
> > Changing ports from the 5000 range to the 4000 range stopped two errors
> > But now I get this..........
> > 
> > INFO: Manager [##0001]: skipping state transfer. No members active in cluster \
> > group 
> > How to I make the member machine in the cluster active?
> 
> 
> There's a cluster configuration option that may be coming into play here: \
> localLoopbackDisabled. Once upon a time, the JDK method: \
> MulticastSocket.setLoopbackMode(boolean disable) did the opposite of what one might \
> think from just the method name - passing in true disabled local receipt of \
> multicast packets. That method has since been deprecated, and Tomcat currently uses \
> this method: <T> DatagramSocket.setOption(SocketOption<T> name, T value)
> which, at least in Java 21, operates as you might expect from the name - specifying \
> true enables multicast loopback. 
> However, there's some interesting logic in Tomcat's handling of \
> localLoopbackDisabled that can inverts the config value based on the Java level, \
> along with this comment: Java < 14, a value of true means loopback is disabled. \
> Java 14+ a value of true means loopback is enabled. 
> Having not dug into the JRE source code for the various Java versions, I'm not yet \
> convinced the version checking logic is correct. You might try setting \
> localLoopbackDisabled to true in your <Membership … /> config to see if that has \
> an effect on your dev system. 
> Also, let us know what Java version you're using.
> 
> - Chuck
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


-- 
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as
half full.
Engineers, of course, understand the glass is twice as big as it needs to be.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]