[jboss-jira] [JBoss JIRA] Updated: (JBAS-772) HA-JNDI multicast reply not reaching client

[Brian Stansberry (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-772?page=all ]

Brian Stansberry updated JBAS-772:
----------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-5.0.0.Beta4)
         Assignee: Brian Stansberry  (was: Jerry Gauthier)

> 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
>             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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira