tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Madhav Bhargava <unmarsh...@gmail.com>
Subject Re: Multicast fails when mcastBindAddress is explicitly set
Date Fri, 29 Jun 2012 16:15:42 GMT
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) <
devlists@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:unmarshall@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
> > <unmarshall@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message