]
Brian Stansberry updated JBAS-772:
----------------------------------
Fix Version/s: JBossAS-5.0.0.CR1
(was: JBossAS-5.0.0.Beta)
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: Jerry Gauthier
Fix For: JBossAS-5.0.0.CR1
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: