https://issues.apache.org/bugzilla/show_bug.cgi?id=48482
Summary: Error running two tomcats in same cluster on same
Windows box
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Windows Server 2008 (Longhorn)
Status: NEW
Severity: major
Priority: P2
Component: Cluster
AssignedTo: dev@tomcat.apache.org
ReportedBy: jo...@jdtangney.com
To summarize:
1) We are using 6.0.18.
2) A single Tomcat works fine and joins the cluster.
3) Two Tomcats on the SAME MACHINE (different ports - duh) but multicasting
to DIFFERENT multicast IPs each join their respective clusters. (yes, two
clusters.)
4) Two Tomcats on the SAME machine multicasting to the SAME multicast IP and
we get "An operation was attempted on something that is not a socket" when
we launch the second tomcat.
5) The exact setup works fine on RHEL and Mac OS X
* This is NOT the 6.0.20 regression
(https://issues.apache.org/bugzilla/show_bug.cgi?id=47308) – we're using
6.0.18.
* This is NOT an issue with Windows getting confused by the bind attribute – it
works fine in cases 2 & 3 above.
Could it be that windows won't allow two apps to multicast to the same address
at the same time?
Here is some log output:
INFO: Initializing Coyote HTTP/1.1 on http-8180
Dec 22, 2009 2:17:07 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 332 ms
Dec 22, 2009 2:17:07 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Dec 22, 2009 2:17:07 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
Dec 22, 2009 2:17:07 PM org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
Dec 22, 2009 2:17:07 PM org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/10.5.1.102:4000
Dec 22, 2009 2:17:07 PM org.apache.catalina.tribes.membership.McastServiceImpl
setupSocket
INFO: Attempting to bind the multicast socket to /224.0.0.0:45564
Dec 22, 2009 2:17:07 PM org.apache.catalina.tribes.membership.McastServiceImpl
setupSocket
INFO: Setting multihome multicast interface to:/10.5.1.102
Dec 22, 2009 2:17:07 PM org.apache.catalina.ha.tcp.SimpleTcpCluster start
SEVERE: Unable to start cluster.
org.apache.catalina.tribes.ChannelException: java.net.SocketException: An
operation was attempted on something that is not a socket; No faulty members
identified.
...
Caused by: java.net.SocketException: An operation was attempted on something
that is not a socket
------------------
Reply from Konstantin Kolinko:
"An operation was tried on something that is not a socket." is the
message that corresponds to the WinSock error code WSAENOTSOCK
(10038), see here:
http://support.microsoft.com/kb/819124
>From TC 6.0.18 source bundle and from JDK sources it can be seen that
Line 206 in McastServiceImpl is
socket.setInterface(mcastBindAddress);
and that results in some setOption(SocketOptions.IP_MULTICAST_IF) call
that goes into native code.
see java.net.SocketOptions
Regarding the listening on the same address/port:
With some search I found the following blog entry by Anthony Wong:
http://blogs.msdn.com/anthonywong/archive/2005/09/30/475884.aspx
that says:
[cite]
Because multicasting is a one to many communication, there maybe some
occasions when you would like multiple UdpClient instances on the same
machine to receive data from the same multicast group and port. To do
this, you would need to set the SO_REUSEADDR socket option before
joining the multicast group.
[/cite]
The relevant option in java.net.SocketOptions is
SocketOption.SO_REUSEADDR and it is settable through
DatagramSocket.setReuseAddress().
The JavaDoc for SO_REUSEADDR says that "it is set by default for
MulticastSockets", and it is indeed so: you can see in JDK sources
that java.net.MulticastSocket class constructor calls
setReuseAddress(true).
The JavaDoc for setReuseAddress() says that support for this option is
system-dependent, and also suggests you to check result of
getReuseAddress(), that "will be false if it is not supported".
In the list of errors there is WSAEADDRINUSE error (Address already in
use). I wondered why it was not used, because it is directly relevant
to the SO_REUSEADDR, if that is actually the cause, but I see that
that WSAEADDRINUSE is not listed among the codes returned by the
setsockopt() socket API function:
http://www.sockets.com/winsock.htm#SetSockOpt
http://msdn.microsoft.com/en-us/library/ms740476%28VS.85%29.aspx
WSAEADDRINUSE error code is returned by the bind() operation.
Returning back to the java code of McastServiceImpl.java of tribes
TC 6.0.18:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?view=markup
Current code:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?view=markup
Locking in McastServiceImpl.setupSocket()
1) I wonder whether "address" is ignored at all, unless "bind" is also set.
I mean, in the first lines of the method
if (mcastBindAddress != null) {
try {
log.info("Attempting to bind the multicast socket to
"+address+":"+port);
socket = new MulticastSocket(new
InetSocketAddress(address,port));
why mcastBindAddress is used in the if() condition, and not address.
This code was introduced in rev.586228
http://svn.apache.org/viewvc/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?r1=586227&r2=586228&;
2) John Tangney,
do you see the following one or two INFO messages in Tomcat log:
log.info("Attempting to bind the multicast socket to "+address+":"+port);
log.info("Binding to multicast address, failed. Binding to port only.");
3)
It is possible to create unbound MulticastSocket, by passing a null
instead of SocketAddress to its constructor.
Maybe the socket.setInterface(mcastBindAddress); call will succeed
if we create an unbound socket with "new MulticastSocket(null)", make
setInterface() call, and call bind() later.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
