I'd write a simple test program to see. > -----Original Message----- > From: Madhav Bhargava [mailto:unmarsh...@gmail.com] > Sent: Friday, June 29, 2012 10:16 AM > To: Tomcat Users List > Subject: Re: Multicast fails when mcastBindAddress is explicitly set > > Hi Filip, > > We as development teams do not have access to the production VM/HV's but > it > was told to us that multicast is enabled and they have explicitly > checked > the Xen virtual bridges/switch to check if the multicast is blocked but > it > does not seem to be. > > At this point in time we do not know if the issue is because of apache > tribes or it is just related to HV configuration. > > Best Regards, > Madhav > > On Fri, Jun 29, 2012 at 9:36 PM, Filip Hanik (mailing lists) < > devli...@hanik.com> wrote: > > > Sounds like you need to enable multicasting. This would be a > VM/hypervisor > > configuration issue. > > > > Filip > > > > > -----Original Message----- > > > From: Madhav Bhargava [mailto:unmarsh...@gmail.com] > > > Sent: Friday, June 29, 2012 10:04 AM > > > To: users@tomcat.apache.org > > > Subject: Re: Multicast fails when mcastBindAddress is explicitly set > > > > > > Hi All, > > > > > > Ok we got resolution for the below exception. The problem was that > both > > > IPV4 and IPv6 addresses were enabled for the multihome machine. We > > > switched > > > to IPv6 addresses and the issue was no longer there. However there > is > > > still > > > one issue: > > > > > > With machines on different hypervisors the multicast traffic seems > to be > > > blocked. VM's on different Hypervisors are not able to get presence > or > > > any > > > other message from each other. So neither the discovery works nor > inter > > > node communication because there is no knowledge of the other VMs > > > > > > Best Regard, > > > Madhav > > > > > > On Fri, Jun 29, 2012 at 5:58 PM, Madhav Bhargava > > > <unmarsh...@gmail.com>wrote: > > > > > > > Hi All, > > > > > > > > We are using Apache Tribes 7.0.2. We use it for node discovery and > p2p > > > > communication. > > > > We are currently running into a problem where the discovery fails > on > > > > multihomed machines (multiple IP's). We were not sure to which IP > the > > > > multicast bind address was getting bound to, so we thought of > > > explicitly > > > > binding the interface via "mcastBindAddress" property. However > when we > > > set > > > > this property then we get the following exception: > > > > > > > > Exception occured: java.io.IOException: Invalid argument; No > faulty > > > > members identified.org.apache.catalina.tribes.ChannelException: > > > > java.io.IOException: Invalid argument; No faulty members > identified. > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(Channe > > > lCoordinator.java:178) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordin > > > ator.java:99) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInt > > > erceptorBase.java:162) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor > > > .start(MessageDispatchInterceptor.java:153) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInt > > > erceptorBase.java:162) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:41 > > > 9) > > > > > > > > at > > > > > > > > com.sap.it.gizmos.diag.TribesConfigurator.run(TribesConfigurator.java:10 > > > 9) > > > > > > > > at > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > > > > at > > > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > > > > > > > > at > java.util.concurrent.FutureTask.run(FutureTask.java:166) > > > > > > > > at > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav > > > a:1110) > > > > > > > > at > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja > > > va:603) > > > > > > > > at java.lang.Thread.run(Thread.java:782) > > > > > > > > Caused by: java.io.IOException: Invalid argument > > > > > > > > at java.net.PlainDatagramSocketImpl.send(Native Method) > > > > > > > > at java.net.DatagramSocket.send(DatagramSocket.java:675) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.membership.McastServiceImpl.send(McastService > > > Impl.java:503) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.membership.McastServiceImpl.send(McastService > > > Impl.java:480) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServic > > > eImpl.java:269) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.membership.McastService.start(McastService.ja > > > va:386) > > > > > > > > at > > > > > > > > org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(Channe > > > lCoordinator.java:167) > > > > > > > > ... 12 more > > > > > > > > So we wrote a simple test program (attached) which fails on multi- > home > > > > machines. We also wrote another test program where we just used > simple > > > > java.net.MulticastSocket, set the multicast interface (using > > > setInterface) > > > > to one of the interfaces and tried to send a Datagram packet and > it > > > was > > > > able to send. > > > > > > > > So now we wonder: > > > > > > > > 1. How do you explicitly set the multicast interface on the group > > > channel > > > > in apache tribes? > > > > 2. I assume that tcpListenHost is the IP address that gets > advertised > > > when > > > > it joins the group and mcastBindAddress is the interface used to > send > > > out > > > > messages over a multicast socket. Is my assumption right? > > > > > > > > Any help/pointers would be greatly appreciated. > > > > > > > > Best Regards, > > > > Madhav > > > > > > > > > > > > -- > > > > When I tell the truth, it is not for the sake of convincing those > who > > > do > > > > not know it, but for the sake of defending those that do > > > > > > > > > > > > > > > > -- > > > When I tell the truth, it is not for the sake of convincing those > who do > > > not know it, but for the sake of defending those that do > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > -- > When I tell the truth, it is not for the sake of convincing those who do > not know it, but for the sake of defending those that do
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
