]
Brian Stansberry resolved JBAS-772.
-----------------------------------
Fix Version/s: (was: JBossAS-5.0.1.CR1)
Resolution: Out of Date
Assuming this is out of date, as the described behavior of the DetachedHANamingService
sending the autodiscovery response to <client-ip>:1102 does not apply to the current
NamingContext code. The NamingContext by default binds its socket to
InetAddress.anyLocalAddress() (i.e. 0.0.0.0) and an ephemeral port. Not to 1102. One would
have to set jnp.localPort=1102 in one's naming properties to get a NamingContext to
bind its automatic discovery socket to 1102.
As the description describes, DetachedHANamingService sends the reply packet to the
address and port of the sender. I changed the trace level logging of this to show what
happens:
2008-03-24 22:11:39,778 TRACE
[org.jboss.ha.jndi.DetachedHANamingService$AutomaticDiscovery] (JBoss System Threads(1)-9)
Sending AutomaticDiscovery answer: 192.168.1.146:1100 to /192.168.1.145:39397
If I'm missing something here, please attach a unit test showing the exact problem.
HA-JNDI multicast reply not reaching client
-------------------------------------------
Key: JBAS-772
URL:
http://jira.jboss.com/jira/browse/JBAS-772
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Affects Versions: JBossAS-3.2.6 Final
Reporter: SourceForge User
Assigned To: Brian Stansberry
Attachments: DeviceManager.jsp, DeviceModule.java, TelematicsJNDI.java
SourceForge Submitter: rmontag .
I just made some expiriences with the HA-JNDI multicast
and running multiple instances on a single machine. I
encountered some problems...
My setup:
- JBoss 3.2.2
- JDK 1.4.2
- Two instances running on a single W2K-PC,
alternatively I 'm using two instances running on a
single SUN solaris. instance 1 using 1200 as HA-JNDI
port, instance 2 using 1300.
- "JBoss Clustering" documentation, 4. edition
- Standalone testclient (JUnit) on PC or SUN,
configured for Multicast (url-property not set)
The problem:
Case A: Testclient and server instances on PC
Case B: Testclient on PC, server instances on SUN
When starting my testclient and making a lookup via
multicast, both instances receive the GET_ADDRESS
datagram. Then each server send a datagram packet back
NOT using a multcast. Since the testclient opens a
MulticastSocket on the Multigroup port 1102, each
server sends a response datagramm back to <client-ip>:1102.
I encountered two problems with this approach:
1) If client and server are one the same instance like
in case A, they have the same ip-address. In my
environment one server instance always "catches" all
the answers, so the client timed-out with no answers
(Note: On W2K, I set "loopback" to true, on SUN to
false as described in the cluster document).
2) Same problem if two clients on one instance make a
concurrent multicast call (servers on other machine):
Both waiting for responses, only one client catches all
the responses. The second client ever lose.
Two possible solutions come to my mind:
1) Currently the NamingContext opens a MulticastSocket
on the multicast group port. If the client would use a
different dedicated port, he can send his call with the
multicast group address and the server could reply to
<client-ip>:<dedicated client-port> with his answer. No
one else (another client or server) would "catch" the
server response if using different port numbers
(Disadvantage: One additional HA-JNDI JNP property like
"jnp.multicastPort").
2) HANamingService currently sends a response datagram
back to a dedicated IP:port address (Unicast). Why
doesn't the server also sends a multicast call using
the well-known multicast group address to propagate his
answer ? A multicast answer seems to be a clean
solution because: a) All clients waiting for an answer
will receive them and b) other server(s) receiving the
answer will ignore them as they already do now.
Solution 2 simply means exchanging one line in
HANamingService.java:
Instead of
DatagramPacket p = new DatagramPacket (ipAddress,
ipAddress.length, packet.getAddress(), packet.getPort());
do this one:
DatagramPacket p = new DatagramPacket(ipAddress,
ipAddress.length, group, adGroupPort);
Solution 1, as stated above would need one additinal
config property for the client port.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: