Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
Rick, On 4/15/24 08:12, Rick Noel wrote: Hi Chuck, Your suggestion did not work. I defined Membership as suggested... and still getting this in the logs org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at [##0001] 15-Apr-2024 07:55:36.744 INFO [main] org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [##0001]: skipping state transfer. No members active in cluster group Do you think the transfer is not happening because the application is only on one machine? Our Production environment will have our application on two machines but in our dev environment we have only one machine in the "cluster". So we really do not have a "cluster" environment. Again, we would like to know is going on before we introduce clustering in our live environment. We are using Java 17 and Tomcat 10 I've never set up replication in Tomcat, so I may be speaking out of turn. But is it possible that since you have only a single node (right?), Tomcat is really saying "skipping state transfer. No [other] members active in cluster group"? -chris -Original Message- From: Chuck Caldarale Sent: Saturday, April 13, 2024 4:00 PM To: Tomcat Users List Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails On Apr 11, 2024, at 09:07, Rick Noel 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: DatagramSocket.setOption(SocketOption 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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - 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: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
Hi Chuck, Your suggestion did not work. I defined Membership as suggested... and still getting this in the logs org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at [##0001] 15-Apr-2024 07:55:36.744 INFO [main] org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [##0001]: skipping state transfer. No members active in cluster group Do you think the transfer is not happening because the application is only on one machine? Our Production environment will have our application on two machines but in our dev environment we have only one machine in the "cluster". So we really do not have a "cluster" environment. Again, we would like to know is going on before we introduce clustering in our live environment. We are using Java 17 and Tomcat 10 Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Saturday, April 13, 2024 4:00 PM To: Tomcat Users List Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails > On Apr 11, 2024, at 09:07, Rick Noel 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: DatagramSocket.setOption(SocketOption 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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: Tomcat 10 session replication fails
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 wrote: > > > > On Apr 11, 2024, at 09:07, Rick Noel 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: > DatagramSocket.setOption(SocketOption 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 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Jonathan | exabr...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: Tomcat 10 session replication fails
> On Apr 11, 2024, at 09:07, Rick Noel 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: DatagramSocket.setOption(SocketOption 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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: Tomcat 10 session replication fails
Thanks Chuck, 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? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Thursday, April 11, 2024 9:14 AM To: Tomcat Users List Subject: [EXT]Re: Tomcat 10 session replication fails [You don't often get email from n82...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Apr 11, 2024, at 07:56, Rick Noel wrote: > > We have our app running on Tomcat10 and doing clustering,but are getting the > following errors seen int the Catalina log... > > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > waitForSendAllSessions > SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] > received, timing out after [60,068] ms. > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > getAllClusterSessions > WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside > GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date > [4/11/24, 8:13 AM] > 11-Apr-2024 08:14:43.456 > > The error, to me, indicates that the session data is not being sent out. > > We are running this app in our dev environment, and in this dev environment > the app runs on only one machine. > In our live environment the app runs on two machines and traffic goes through > a load balancer. > This may be a dumb question but are we getting these errors because we are > running the app on only one machine, and clustering cannot be done on one > machine? Likely. From the Tomcat clustering doc: If your Tomcat instances are running on the same machine, make sure the Receiver.port attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100 You appear to have configured 5001 as the receiver port on both. > > className="org.apache.catalina.tribes.membership.McastService" > > address="228.0.0.4" > > port="45565" > > frequency="500" > > dropTime="3000"/> > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" > > port="5001" > > selectorTimeout="100" > > maxThreads="6"/> - Chuck CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
