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

List:       tomcat-user
Subject:    Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2024-04-15 15:03:55
Message-ID: d0f910c2-c355-4e6d-b64e-eccbf52616a4 () christopherschultz ! net
[Download RAW message or body]

Rick,

On 4/15/24 08:12, Rick Noel wrote:
> Hi Chuck,
> Your suggestion did not work.
> 
> I defined Membership as suggested.......
> <Membership className="org.apache.catalina.tribes.membership.McastService"
> 	  	  	  	 	                        address="228.0.0.4"
> 	  	  	  	 	                        port="45563"
> 	  	  	  	 	                        frequency="500"
> 	  	  	  	 	                        localLoopbackDisabled="true"
> 	  	  	  	 	                        dropTime="3000"/>
> 
> 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 <n828cl@gmail.com>
> Sent: Saturday, April 13, 2024 4:00 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
> 
> 
> > 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
> 
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

---------------------------------------------------------------------
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]