I think the alternatives for running the Infinispan test suite wrt
multicasting are:
- Use of 127.0.0.1 and ip_ttl=1. This ensures that multicast traffic is
local to the machine on which the test suite is run. This is a good idea
anyway, also for other operating systems. I believe this is already done
- Use of a real IP address and ip_ttl. This would allow the test suite
to work without any routing table changes, as the default route
(0.0.0.0) is used, and it usually points to en0
- Check if there's a multicast route defined before running the test
suite (via a script?) and issue a warning if there isn't... ?
On 11/07/14 17:16, Sanne Grinovero wrote:
Thanks Bela!
it's indeed very annoying for occasional contributors just checking
out the code and firing the testuite.
In Hibernate Search we worked around it by simply avoiding need for
Multicast in the stacks used for testing, but I suspect Infinispan
doesn't have this luxury so it would be nice to find a way to detect
and warn for this?
I guess we could just abort the build with a meaningful message if
you're using OSX, nobody should use it anyway :-P
Sanne
On 11 July 2014 15:51, Bela Ban <bban(a)redhat.com> wrote:
> I added some bits of advice for configuration of IP multicast routes on
> Mac OS X.
>
> This is probably only of concern to those who want to bind to the
> loopback device (127.0.0.1) and multicast locally, e.g. for running the
> test suite.
>
> It is beyond me why a node cannot bind to 127.0.0.1 and use the default
> route (0.0.0.0) for multicasting, e.g. if no multicast route has been
> defined). This works perfectly on other operating systems. If you know,
> please share the solution; then [1] would not be needed...
>
> See [1] for details.
>
> [1]
https://issues.jboss.org/browse/JGRP-1808
>
> --
> Bela Ban, JGroups lead (
http://www.jgroups.org)
--
Bela Ban, JGroups lead (
http://www.jgroups.org)