Hi Joe

My distant transport connector looks like

<transportConnector name="NOCP5-DEFAULT-IN"
                          uri="tcp://tpnocp06v-bus:13080?useLocalHost=false"
                         
discoveryUri="multicast://default?group=NOCP5-DEFAULT"/>

And my corresponding network connector looks like

<networkConnector name="NOCP5-DEFAULT-OUT"
                        uri="multicast://default?group=NOCP5-DEFAULT"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"/>

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.
Eric-AWL




Joe Fernandez wrote:
> 
> What does the transport connector for your 'distant' broker look like?
> Reason I ask is that the wildcard (0.0.0.0) vs localhost IP address issue
> has been biting lots of folks. 
> 
> https://issues.apache.org/activemq/browse/AMQ-2094
> 
> Can you telnet to your 'distant' broker?
> 
> Joe
> http://www.ttmsolutions.com
> 

-- 
View this message in context: 
http://old.nabble.com/MultiCast-Discovery-and-refusal-of-connection-tp28827529p28839417.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to