• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

wrong broker address with multicast lookup

Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

my jms broker (activemq) is installed on server "JMSBROKER".

the connector settings are as following:

<transportConnector name="zTransport" uri="tcp://localhost:61616" discoveryUri="multicast://zNet"/>

<networkConnector name="zJMSNetwork" uri="multicast://zNet" dynamicOnly="true"/>

i have 3 other machines at the same subnet, running the clients that should connect to the broker on JMSBROKER. all clients are run totally in the same way: 3 instances of the same application are running by tomcat containers installed on all of the machines. the clients are using the following discovery uri to find a broker: discovery:(multicast://zNet)?initialReconnectDelay=100
now to the problem itself.
while 2 machines are successfully connecting to the broker, the third one just doesn't make it.
QueueConnection.start() method never returns, there are no exceptions or errors thrown.
when i run netstat command on each of the clients machines i see that those connected show the following:
Proto Local Address Foreign Address State
TCP client_machine's_ip:port JMSBROKER_ip:61616 ESTABLISHED

but on the machine that makes troubles i see the following:
TCP client_machine's_ip:port SYN_SENT

i can't figure out where that (which sometimes turns into is coming from.
when tomcat is down, there is no connection to port 61616, so there is no additional process working with the same port running on this machine.
i guess that multicast broadcast mistakenly returns a wrong ip or something.

has anyone ever seen such behavior and have an idea where should i look for a solution?

thank you!
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic