You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Madhav Bhargava <un...@gmail.com> on 2012/06/29 14:28:05 UTC

Multicast fails when mcastBindAddress is explicitly set

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(ChannelCoordinator.java:178)

        at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:99)

        at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)

        at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:153)

        at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)

        at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:419)

        at
com.sap.it.gizmos.diag.TribesConfigurator.run(TribesConfigurator.java:109)

        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.java:1110)

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: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(McastServiceImpl.java:503)

        at
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:480)

        at
org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServiceImpl.java:269)

        at
org.apache.catalina.tribes.membership.McastService.start(McastService.java:386)

        at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.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

RE: Multicast fails when mcastBindAddress is explicitly set

Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
I'd write a simple test program to see.

> -----Original Message-----
> From: Madhav Bhargava [mailto:unmarshall@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) <
> 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
> > > <un...@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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Multicast fails when mcastBindAddress is explicitly set

Posted by Madhav Bhargava <un...@gmail.com>.
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
> > <un...@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

RE: Multicast fails when mcastBindAddress is explicitly set

Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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
> <un...@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


Re: Multicast fails when mcastBindAddress is explicitly set

Posted by Madhav Bhargava <un...@gmail.com>.
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 <un...@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(ChannelCoordinator.java:178)
>
>         at
> org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:99)
>
>         at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
>
>         at
> org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:153)
>
>         at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
>
>         at
> org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:419)
>
>         at
> com.sap.it.gizmos.diag.TribesConfigurator.run(TribesConfigurator.java:109)
>
>         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.java:1110)
>
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: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(McastServiceImpl.java:503)
>
>         at
> org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:480)
>
>         at
> org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServiceImpl.java:269)
>
>         at
> org.apache.catalina.tribes.membership.McastService.start(McastService.java:386)
>
>         at
> org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.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