This discussion is archived
10 Replies Latest reply: Jun 28, 2011 9:50 AM by 452196 RSS

Multicast and localhost

452196 Journeyer
Currently Being Moderated
Maybe not exactly a Java question, but it seems to apply to two disparate Java packages so people around here might know.

When, some time ago, I set up Eclipselink cache coordination I found that the default discovery method was to advertise the presence of an instance with a multi-cast to tell other instances where to connect. However the connection information that was sent in the multicast was "localhost", completely useless, of course. I actually had to override some methods to force the multicast to contain the actual domain name of the server doing the broadcast. There was no properties setting to change it.

Now I seem to be getting exactly the same thing trying to set up activeMQ. When each machine receives the broadcast from the other it tries to connect to itself, rather than the other machine.

On both the machines localhost resolves to the loopback address, not the actual IP of the machine in question.

What gives here? It seems more than a coincidence that two well-established packages appear to make the same fundamental error.

Of course I'm setting up activeMQ from the examples given in the web site, I'm not deeply into it yet, but the documentation never shows anything other than localhost as a host name.

Should localhost resolve to the machine's actual IP?
  • 1. Re: Multicast and localhost
    802889 Explorer
    Currently Being Moderated
    No, 'localhost' should resolve to 127.0.0.1 (or ::1).

    In what way are you selecting the current address of the system? It looks like you are receiving the loopback interface, instead of (one of) the external network interfaces.

    Edited by: EJP on 25/06/2011 20:11: clarified your first sentence via punctuation.
  • 2. Re: Multicast and localhost
    452196 Journeyer
    Currently Being Moderated
    TheAvalanche wrote:
    No, 'localhost' should resolve to 127.0.0.1 (or ::1).
    It does. That's what I thought.

    In what way are you selecting the current address of the system? It looks like you are receiving the loopback interface, instead of (one of) the external network interfaces.
    I think the idea is that the multicast message contains the address of the server that sends it. When I got the cache coordination I wrote a simple sniffer and saw that the address in the packet was literally "localhost". When I put my own code in and overrode it with the domain name of the server, it worked.

    I don't understand why I had to hack it, has it ever worked?

    Now I get the same on an unrelated bit of software.
    >
    Edited by: EJP on 25/06/2011 20:11: clarified your first sentence via punctuation.
  • 3. Re: Multicast and localhost
    EJP Guru
    Currently Being Moderated
    The source address in the datagram can't be 'localhost', because it is numeric, not text. Are you rolling your own? If so, don't: use what is already provided. Seethe Javadoc for DatagramPacket. I doubt that any sane IP stack would put 127.0.0.1 in the source-address.
  • 4. Re: Multicast and localhost
    452196 Journeyer
    Currently Being Moderated
    No these are datagrams generated by the discovery systems of eclipselink and activemq using recomended configurations. That's what baffles me.
  • 5. Re: Multicast and localhost
    EJP Guru
    Currently Being Moderated
    I'm still not clear whether you're referring to something inside the datagram or the source address that comes with the datagram. If the latter and it is 127.0.0.1 it can only come from the local system.
  • 6. Re: Multicast and localhost
    452196 Journeyer
    Currently Being Moderated
    In the Eclipselink case my sniffer discovered that the body of the datagram contained what should have been the domain name of the server, but was in fact "localhost". I'm going to have to dig out that sniffer code I wrote and have a look exactly what's coming from activeMQ, but the symptoms are certainly the same i.e. each broker is, once the other is started, repeatedly trying to connect to itself on the loopback interface.

    I've been looking through a lot of examples of activeMQ configuration, and no URL is ever used that doesn't have "localhost" for a domain.

    Eclipselink was baffling because I don't see how it could possibly work without overriding one of the standard classes with my own and hacking the domain name being broadcast. Now I get the same thing on activeMQ so I wonder if there's something strange about my system.
  • 7. Re: Multicast and localhost
    EJP Guru
    Currently Being Moderated
    Trying to connect to itself, or to the other broker?

    If it's trying to connect to itself on the loopback interface it all seems reasonable to me: why do you care?

    If it's trying to connect to the other broker and the other broker isn't on the localhost that could be a problem, but it's not what you've described so far.
  • 8. Re: Multicast and localhost
    452196 Journeyer
    Currently Being Moderated
    EJP wrote:
    Trying to connect to itself, or to the other broker?
    Clearly it should be connecting to the other broker. It tries to connect to itself on a port that it's not listening on, and it doesn't connect to the other broker.
    If it's trying to connect to itself on the loopback interface it all seems reasonable to me: why do you care?
    For one thing it keeps trying, producing copious log records but more importantly it doesn't connect to the other broker.

    >
    If it's trying to connect to the other broker and the other broker isn't on the localhost that could be a problem, but it's not what you've described so far.
    The other broker isn't on localhost, what would be the point?

    Edited by: malcolmmc on 27-Jun-2011 18:32
  • 9. Re: Multicast and localhost
    802889 Explorer
    Currently Being Moderated
    malcolmmc wrote:
    EJP wrote:
    Trying to connect to itself, or to the other broker?
    Clearly it should be connecting to the other broker. It tries to connect to itself on a port that it's not listening on, and it doesn't connect to the other broker.
    If it's trying to connect to itself on the loopback interface it all seems reasonable to me: why do you care?
    For one thing it keeps trying, producing copious log records but more importantly it doesn't connect to the other broker.
    If it's trying to connect to the other broker and the other broker isn't on the localhost that could be a problem, but it's not what you've described so far.
    The other broker isn't on localhost, what would be the point?

    Edited by: malcolmmc on 27-Jun-2011 18:32
    http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination seems to suggest you need to configure EclipseLink on each server with its own URL (with its external hostname) for access. Maybe if this is not specified, this setting will defauts to localhost?

    It is old, but I think this thread may also be helpful: Cache Coordination RMI  in Weblogic - problems
  • 10. Re: Multicast and localhost
    452196 Journeyer
    Currently Being Moderated
    Thanks, that's an interesting article (which I doubt existed when I had to deal with the problem).

    I've now got my activeMQ servers talking to one another by setting the service URI to tcp://0.0.0.0:0 (not mentioned in the documentation, but some examples in default configuration.

    If you put the actual domain name of the server on there it seems to substitute xxx.local for the domain name.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points