[jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics uses hard-coded IPv4 multicast address

Tue May 12 18:25:57 EDT 2009

    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12467103#action_12467103 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

There was a related issue created by Brian (JBAS-6873) to allow the AS to overcome this use of fixed diagnostics addresses by using the UDP protocol parameters:

Some excerpts from email discussions follow:

Richard:

I found that the multicast binding errors mentioned below disappear if I add the following lines to the file

$JBOSS_DIST/server/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml:

enable_diagnostics="true"
diagnostics_addr="ff02::1:2:5"
diagnostics_port="7500"

where the diagnostics multicast address and port were of my choosing. AS far as I know we don't have a property in the AS to specify these values.

Here is the revised output:

16:35:19,970 INFO  [DefaultPartition] Initializing partition DefaultPartition
16:35:20,231 WARN  [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument
16:35:20,289 INFO  [STDOUT]
---------------------------------------------------------
GMS: address is fe80:0:0:0:215:17ff:fe2d:6821:44270 (cluster=DefaultPartition)
---------------------------------------------------------
16:35:20,491 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
16:35:22,387 INFO  [DefaultPartition] Number of cluster members: 1
16:35:22,399 INFO  [DefaultPartition] Other members: 0
16:35:22,609 INFO  [RPCManagerImpl] Received new cluster view: [fe80:0:0:0:215:17ff:fe2d:6821:44270|0] [fe80:0:0:0:215:17ff:fe2d:6821:44270]
16:35:22,611 INFO  [RPCManagerImpl] Cache local address is fe80:0:0:0:215:17ff:fe2d:6821:44270
16:35:22,615 INFO  [RPCManagerImpl] state was retrieved successfully (in 2.03 seconds)
16:35:22,652 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.CR1
16:35:22,652 INFO  [DefaultPartition] Fetching serviceState (will wait for 30000 milliseconds):
16:35:22,654 INFO  [DefaultPartition] State could not be retrieved (we are the first member in group)
16:35:22,978 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/fe80:0:0:0:215:17ff:fe2d:6821
16:35:22,987 WARN  [DetachedHANamingService$AutomaticDiscovery] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument
16:35:22,991 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /fe80:0:0:0:215:17ff:fe2d:6821%8:1102, group=ff02::1:2:3, HA-JNDI address=fe80:0:0:0:215:17ff:fe2d:6821:1100
16:35:24,457 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha

Don't know what you want to do about this? Create a JIRA?

Brian:

Are you asking whether there should be a JIRA for the requirement to configure the diagnostic_addr?  Or the WARN for the binding to the multicast address?

Re: the diagnostic address, there should be a JBAS JIRA to add this to the standard configs. And now there is. :)
https://jira.jboss.org/jira/browse/JBAS-6873

That only applies to community AS 5.1, and hence EAP 5.  For the EAP 4.x releases we are talking about, generally we don't like changing configurations in CP as it makes installing the CP harder.  But, perhaps a well written JBPAPP JIRA would still be useful, even if we reject it as "Won't Fix". The JIRA would document the issue in the place people search for issues. 

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira