Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails

2024-04-15 Thread Christopher Schultz

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

2024-04-15 Thread Rick Noel
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