1 of 1 people found this helpful
I am trying to fix an undesirable new behavior of HornetQ 2.3 (vs 2.2.5) where it seems to be a little too promiscuous. That is, the server would pick up discovery group broadcasts from other clusters and attempt (unsuccessfully) to join them. I never noticed this behavior before with 2.2, but obviously I'll need to adjust the configuration for 2.3.
That behaviour hasnt changed, you need to use different addresses for different clusters if they are on the same network.
With 2.2, Netty has a parameter "host". HornetQ 2.3's Netty additionally has "local-address". For the purposes of configuring an acceptor, host and local-address seem like they should be synonyms. But I get inconsistent behavior depending on whether I use either or both parameters. Could someone clarify the relationship between these two parameters?
The local address/port are what a client will bind its socket too when it creates the connection.
I'll follow up my own post with my findings for the sake of completeness.
The "suddenly gone promiscuous" behavior was due to a misconfiguration. Because hornetq-configuration.xml no longer allowed the "clustered" element, I removed a <clustered>false</clustered> entry from one file intended to configure an unclustered server. Without an explicit directive to disable clustering, clustering was enabled. I took care of that by adjusting other parts of the cluster configuration.
As to host vs local-address, I looked in NettyConnector.java and can confirm that when configuring a connector, only local-address is used for setting the local address HornetQ binds to for the connector. What confused me is that the "host" parameter is used for the same purpose if you are configuring an acceptor (local-address is not permitted when configuring the acceptor). Basically,
- host: destination
- local-address: local bind address
- host: local bind address
- local-address: not allowed