discoveryUri in transportConnector and uri in networkConnector partially ignored if multicast

• Key: AMQ-1489
• Type: Bug
• Status: Reopened
• Priority: Major
• Assignee: David Jencks
• Reporter: Gerald Loeffler
• Component/s: Connector
• Affects Version/s: 5.0.0, 4.1.1
• Fix Version/s: 4.1.3

Description

This bug relates to the MulticastDiscoveryAgent and was discovered when

1. the discoveryUri of a transportConnector is a multicast-uri such as

<transportConnector uri="..." discoveryUri="multicast://239.3.7.0:37000" />

or

2. the uri of a networkConnector is a multicast-uri such as

<networkConnector name="..." uri="multicast://239.3.7.0:37000">

In these cases, the uri is partially ignored by the MulticastDiscoveryAgent: the host-name of the uri (239.3.7.0) is extracted and used as the group name by the MulticastDiscoveryAgent. But the actual multicast group IP is always 239.255.2.3 and the multicast port is always 6155, regardless of what the actual uri is in the configuration.

The reason for this is that MulticastDiscoveryAgentFactory creates a new MulticastDiscoveryAgent and sets the group based on the uri's host, but fails to set the discoveryURI itself. MulticastDiscoveryAgentFactory should be corrected to do this:

MulticastDiscoveryAgent rc = new MulticastDiscoveryAgent();
rc.setDiscoveryURI(uri); // missing
rc.setGroup(uri.getHost());

Without the above setting of the discoveryURI the MulticastDiscoveryAgent always uses the DEFAULT_DISCOVERY_URI_STRING which is "multicast://239.255.2.3:6155", explaining the erroneous behaviour described above.

kind regards,
gerald

http://www.gerald-loeffler.net

Comments

[David Jencks]

Fixed rev 640636.

[Ari Cooperman]

This fix is missing in 5.+

[David Jencks]

I'm no expert in how this is supposed to work, but the comment in the trunk code makes me wonder if the patch is correct.

Without the patch, a URI with ?discoveryURI=foo will result in setting the discoveryURI and other URIs will use the default.

With the patch, IIUC, the default will never be used.

[David Jencks]

After further thought I've reverted the patch as I think it can't possibly be correct to always overwrite the default multicast info. I don't understand how this is supposed to work well enough to fix it without help.

It looks to me as if it is possible to specify the discoveryURI with the current code by using configurations like

<transportConnector uri="..." discoveryUri="multicast://239.3.7.0:37000?discoveryURI=multicast://239.3.7.0:37000" />

and

<networkConnector name="..." uri="multicast://239.3.7.0:37000?discoveryURI=multicast://239.3.7.0:37000">

i.e. specifying the discoveryURI as a uri query parameter even when directly specifying the discoveryURI. If this is the expected usage then perhaps a documentation update is what is required, although the first example looks weird to me. Perhaps a flag as to whether the uri is intended to be the discovery URI would be more appropriate or perhaps the code processing the first case could add the discoveryURI as a parameter itself.

[David Jencks]

Did not get fixed in 4.1.2

[Joe Fernandez]

Submitted the patch for review. With this patch, you don't have to use a query parameter to specify a host:port. You can simply specify it as follows: multicast://<host>:<port>. However, the patch doesn't preclude you from specifying the discoveryURI via a query paramter; doing so will override <host>:<port> provided via the URI.

Also, the default group value, which is "default", can only be overriden via a query parameter; as I think it should. For example, with the URI below, the agent will end up using the default IP and port number, but is given a group name of "foo".

multicast://default?group=foo