activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric-AWL <>
Subject Re: MultiCast Discovery and refusal of connection
Date Thu, 10 Jun 2010 06:51:01 GMT

Hi Joe

My distant transport connector looks like

<transportConnector name="NOCP5-DEFAULT-IN"

And my corresponding network connector looks like

<networkConnector name="NOCP5-DEFAULT-OUT"

Some of my brokers have a "duplex" connection without the transport
connector. Some others have a "not duplex" connection with the corresponding
network connector in which case, they are TCP connected each others.

It is a complex network of brokers architecture.

The problem is that, sometimes, when active network connections are normally
broken (network fault for example), the broker doesn't succeed in
re-establishing them when the error is corrected.
If I start again the faulty broker, some faulty connections are up again,
and some others (that were previously correctly up) can't be established
.... very strange.
The number of active connections is not always the same.

I don't understand. We tried with the ActiveMQ 5.2 version and the
fuse-5.3-0.6 version.

I just wonder if there can be a "normal" reason which can explain that
ActiveMQ refuses to connect to a distant discovered broker.

We have an own external mechanism which transform multicast frames to TCP
frames, and TCP frames to multicast frames back. (A gateway between
different sub-networks). Perhaps the problem is here ....

Thank you for your answer.

Joe Fernandez wrote:
> What does the transport connector for your 'distant' broker look like?
> Reason I ask is that the wildcard ( vs localhost IP address issue
> has been biting lots of folks. 
> Can you telnet to your 'distant' broker?
> Joe

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message