Comments on: Synchronizing Transfer ORM in a Model-Glue/Coldspring cluster with TransferSync http://www.ghidinelli.com/2008/10/16/synchronizing-transfer-orm-in-a-model-gluecoldspring-cluster-with-transfersync Thu, 01 Jun 2017 18:51:00 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: TransferSync stable on ActiveMQ 5.2.0 » ghidinelli.com http://www.ghidinelli.com/2008/10/16/synchronizing-transfer-orm-in-a-model-gluecoldspring-cluster-with-transfersync/comment-page-1#comment-53815 TransferSync stable on ActiveMQ 5.2.0 » ghidinelli.com Mon, 26 Jan 2009 19:35:52 +0000 http://www.ghidinelli.com/?p=217#comment-53815 [...] my post on synchronizing Transfer ORM with TransferSync, I used Apache ActiveMQ 5.1.0 which was not reliable for me. After about a week of uptime, one of [...] [...] my post on synchronizing Transfer ORM with TransferSync, I used Apache ActiveMQ 5.1.0 which was not reliable for me. After about a week of uptime, one of [...]

]]> By: brian http://www.ghidinelli.com/2008/10/16/synchronizing-transfer-orm-in-a-model-gluecoldspring-cluster-with-transfersync/comment-page-1#comment-51759 brian Tue, 28 Oct 2008 17:43:23 +0000 http://www.ghidinelli.com/?p=217#comment-51759 A note about dev/staging servers. In our network we have a separate server for staging and we do NOT want this machine to be part of the ActiveMQ cluster. In short, changes made on the test server should not cause the production machines to discard their objects. Assuming you don't add the IPTABLES rules listed above, you will get error messages from the other nodes like: <code> INFO DiscoveryNetworkConnector - Establishing network connection between from vm://localhost to tcp://web1:61616 WARN DiscoveryNetworkConnector - Could not start network bridge between: vm://localhost and: tcp://web1:61616 due to: java.net.NoRouteToHostException: No route to host INFO DemandForwardingBridge - localhost bridge to Unknown stopped </code> You can eliminate these by adding one simple rule on the box you wish to exclude: <code>-A OUTPUT -p udp -d 239.255.2.3 --dport 6155 -j DROP</code> This will stop the machine from broadcasting UDP packets that tell other machines "hey, connect to me!" A note about dev/staging servers. In our network we have a separate server for staging and we do NOT want this machine to be part of the ActiveMQ cluster. In short, changes made on the test server should not cause the production machines to discard their objects.

Assuming you don’t add the IPTABLES rules listed above, you will get error messages from the other nodes like:


INFO DiscoveryNetworkConnector - Establishing network connection between from vm://localhost to tcp://web1:61616
WARN DiscoveryNetworkConnector - Could not start network bridge between: vm://localhost and: tcp://web1:61616 due to: java.net.NoRouteToHostException: No route to host
INFO DemandForwardingBridge - localhost bridge to Unknown stopped

You can eliminate these by adding one simple rule on the box you wish to exclude:

-A OUTPUT -p udp -d 239.255.2.3 --dport 6155 -j DROP

This will stop the machine from broadcasting UDP packets that tell other machines “hey, connect to me!”

]]>