In short: I'm hoping there's a way to get the multicast auto-discovery stuff to cross subnet boundaries.
I have a production set up in which we have two subnets.
- HornetQ clients
- HornetQ itself
The reason we have two subnets is because we're transmitting sensitive data and our security folks require that there be a firewall between the clients that transmit the data and the points where the data might be written down (including databases). Our assumption is that under certain conditions, HornetQ may need to write down the messages.
(For the most part, we need to be able to demonstrate certain things to certain review bodies, so this isn't really a discussion about whether we really, really need to do this. There's no arguing with certain industry watchdogs over the "spirit" of a constraint rather than the "letter".)
Anyway, we're using multicast in another context in this same environment, and the way we get it to work (in Java) is that we set TTL on the multicast socket to 32.
Here's a capture from the Hornet Q socket capture:
IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 1164 bytes IP: Identification = 1523 IP: Flags = 0x0 IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 2960 bytes IP: Time to live = 1 seconds/hops IP: Protocol = 17 (UDP) IP: Header checksum = a34e IP: Source address = 220.127.116.11, 18.104.22.168 IP: Destination address = 22.214.171.124, 126.96.36.199 IP: No options IP: UDP: [1144 byte(s) of data, continuation of IP ident=1523]
According to my colleague in Ops: "Here is the IP header from a multicast packet originating from the hornetq service. Looking at the time to live header line you see it’s set to 1. This is the java default and we need to modify that so multicast travels across gateways. Currently in our locally developed apps we set this to 32."
Here is where I see the multicast socket creation in the source code.
Line 111 in file ./src/main/org/hornetq/core/cluster/impl/DiscoveryGroupImpl.java
socket = new MulticastSocket(groupPort);
In our apps, we "fix" this problem by doing something like:
Is there a way we can add this as part of the cluster configuration?
Is there a way to get this working immediately in the GA release?