On 09/02/2024 07:51, Manak Bisht wrote:
On Fri, Feb 9, 2024 at 3:25 AM Mark Thomas <ma...@apache.org> wrote:
Same JRE?
Yes, 8.0.402
Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm
not sure how the clustering would behave with 0.0.0.0
Using 0.0.0.0 as the address for the receiver is going to cause
problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too
deeply into things as a) I am short of time and b) I'm not convinced
this should/could work anyway.
What seems to happen is that the use of 0.0.0.0 confuses the cluster as
to which node is which - I think because multiple nodes are using
0.0.0.0. That causes the failure of the initial state synchronisation.
That's the problem really. Using the DNS name or IP address causes the
following error -
I am as sure as I can be that the issue you are seeing is environmental.
I have configured my test cluster with:
- your cluster configuration with changes to host names and IP addresses
- Java 8.0.402
- Tomcat 8.5.x
With the Receiver using address="0.0.0.0" I see the same issues you do.
I'm not yet convinced that is a bug.
With the Receiver using address="hostname" the cluster starts but
doesn't work. Examining the logs shows that is because the host name
resolves to a loopback address. I'd class that as behaving as expected.
I coudl always change the host's config if I wanted the name to resolve
to the public IP.
With the Receiver using address="ip-address" the cluster start and log
messages show that cluster state is exchanged within a few milliseconds.
That leads me to conclude that the BindException you see is a
configuration and/or envornmental issue although I don't see why your
simple test works but clustering doesn't. Perhaps a conflict with
something else in your Tomcat configuration?
Somethign to try is starting Tomcat with the Receiver using 0.0.0.0 and
then using nestat to see which address/port combinations are being used.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org