Bugs item #633392, was opened at 2002-11-04 09:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866
Category: Clustering
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Simo Arajarvi (simo22)
Assigned to: Sacha Labourey (slaboure)
Summary: HANamingService uses MulticastSockets
Initial Comment:
HANamingService uses MulticastSocket instead of
JavaGroups methods for automatic discovery.
This seems to cause discovery mechanism to find HA
JNDI peers beyond the intended cluster partition.
See: AutomaticDiscovery -inner class of
org.jboss.ha.jndi.HANamingService.
OS: Win2K, Solaris
JDK: 1.4
Server trace: n/a
Reproduce: Start two cluster partitions (pA,pB) within
same subnet. Both partitions contain a HA-JNDI bound
object with same name but different implementation. if
partition pA becomes unavailable, clients using it's
services will resort to using pB instead of failing as
expected.
This issue was discovered by Scott Stark and Munir
Hafez at the Seattle advanced training seminar (Oct 21-
24, 2002)
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2002-11-14 10:59
Message:
Logged In: YES
user_id=175228
No, the problem Simo showed me was that the cluster node
would not even start because of this call to
java.net.MulticastSocket inside of the HANamingService (the
server side code):
public AutomaticDiscovery () throws Exception
{
socket = new java.net.MulticastSocket (adGroupPort);
group = InetAddress.getByName (adGroupAddress);
socket.joinGroup (group);
String address = getBindAddress();
if (address == null)
ipAddress = (java.net.InetAddress.getLocalHost
().getHostAddress() +
":" + port).getBytes();
else
ipAddress = (address + ":" + port).getBytes();
log.info("Listening on " + socket.getInterface() + ":" +
socket.getLoca
lPort());
}
Do the test yourself. Disable multicast on your box, configure
JG to not use multicast and try starting the
HANamingService.
----------------------------------------------------------------------
Comment By: Sacha Labourey (slaboure)
Date: 2002-11-14 10:41
Message:
Logged In: YES
user_id=95900
No, the problem is on the client. Remember: the discovery
features aims to discover at least one server by a *client*. On
the server, JG is implicitly used because the answer send
from the server to the client is a clustered proxy (i.e. a proxy
containing the list of all available servers) and this clustered
proxy is built from information obtained from JG.
On the client side, we don't use JG. When no server is
available, we have only one way to try to discover one:
through multicast. This is what we do.
The complain is about the client not being able to discover a
HA-JNDI service for a *given* partition (and only this specific
partition). Currently, if more than one partition is available on
a network, an automatic discovery will return a clustered
proxy for one of the partition (randomly selected) => non-
deterministic!
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-11-13 13:35
Message:
Logged In: YES
user_id=175228
The problem is not on the client. The problem is with the
AutomaticDiscovery not using JG to do its discovery on the
server side. If you configure a cluster to use only TCP
because you are running in a network that does not have
multicast enabled, the HA-JNDI service will not start because
of the AutomaticDiscovery reliance on multicast.
----------------------------------------------------------------------
Comment By: Sacha Labourey (slaboure)
Date: 2002-11-04 10:07
Message:
Logged In: YES
user_id=95900
The problem is not the fact that JG is not used to discover HA-
JNDI server: we don't want any JG code on the client side.
Instead we will add a new property in jndi.properties to
specify which partition is looked for. It will also be possible to
change the multicast address used for discovery.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
