activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John McCarthy (JIRA)" <>
Subject [jira] Updated: (AMQ-2842) Multicast discovery failure due to "alive" heartbeats not received on some multihomed systems
Date Tue, 20 Jul 2010 23:42:51 GMT


John McCarthy updated AMQ-2842:

    Attachment: MulticastDiscoveryAgent_joinNetworkInterface.patch

Patch file for adding {{joinNetworkInterface}} parameter to MulticastDiscoveryAgent.

> Multicast discovery failure due to "alive" heartbeats not received on some multihomed
> ---------------------------------------------------------------------------------------------
>                 Key: AMQ-2842
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Connector
>    Affects Versions: 5.3.2
>         Environment: Windows 2008, multiple NICs / IP addresses
>            Reporter: John McCarthy
>            Priority: Minor
>         Attachments: MulticastDiscoveryAgent_joinNetworkInterface.patch
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
> Ocassionaly, on some multihomed Windows 2008 systems, brokers cannot be discovered using
multicast discovery.  After investigating, it was determined that the broker "alive" heartbeats
were not being received by the MulticastDiscoveryAgent.  This was traced back to issues with
joining the multicast group using the default network interface.  As Windows socket documentation
> bq. It is recommended that a local IPv4 address or interface index always be specified
in the imr_interface member of the ip_mreq  structure, rather than use the default interface.
This is particularly important on computers with multiple network interfaces and multiple
public IPv4 addresses. ([source|])
> [AMQ-2381]  was submitted with similar issues for multihomed Windows systems.  It was
resolved by adding network interface parameters that plumbed through to {{MulticastSocket.setNetworkInterface(NetworkInterface)}}
and {{MulticastSocket.setInterface(InetAddress)}}.  However, this set only affects what network
interface the multicast traffic is sent on.  Another parameter is also needed to control what
network interface multicast traffic is received on, plumbed through to {{MulticastSocket.join(SocketAddress,
NetworkInterface)}}.  (The same {{networkInterface}} parameter could be overloaded, but this
could be troublesome for backwards compatibility with the current URI specification.)  
> The attached patch is a proposal to add a new {{joinNetworkInterface}} parameter plumbed
through to {{MulticastSocket.join(SocketAddress, NetworkInterface)}}.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message