Interfaces Configuration

[James Cook]

I don't know the IP address of my computer at runtime because it is a dynamic EC2 instance. I would prefer if Hazelcast would just use 0.0.0.0 for its interface binding. However when I attempt to do this using the configuration:

     <interfaces enabled="true">
               <interface>0.0.0.0</interface>
       </interfaces>

I get the following exception:

Caused by: 

java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: Hazelcast CANNOT start on this node. No matching network interface found. |Interface matching must be either disabled or updated in the hazelcast.xml config file.

at com.hazelcast.impl.FactoryImpl.newHazelcastInstanceProxy(FactoryImpl.java:141)

at com.hazelcast.core.Hazelcast.getDefaultInstance(Hazelcast.java:77)

at com.tracermedia.hazelcast.HazelcastBootstrap.init(HazelcastBootstrap.java:21)

I also tried:

     <interfaces enabled="false">
               <interface>0.0.0.0</interface>
       </interfaces>

But it ends up binding to the 169.* address, which prevents any hope of clustering on our 10.16.151.* address range.

    Members [1] {

Member [169.254.165.32:9350] this

    }

Is there way to accomplish this? 

[Talip Ozturk]

Which version of Hazelcast?

How about this?

<interfaces enabled="true">
<interface>10.16.151.*</interface>
</interfaces>

http://twitter.com/oztalip

> --
> You received this message because you are subscribed to the Google Groups
> "Hazelcast" group.
> To post to this group, send email to haze...@googlegroups.com.
> To unsubscribe from this group, send email to
> hazelcast+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hazelcast?hl=en.
>

[James Cook]

Thats what we did to support testing on our local test network, but it doesn't help when we deploy to EC2. Wouldn't it be better to support 0.0.0.0 as a binding option, especially if it is explicitly set in the config?

There are, of course, other issues when deploying to EC2 since there is no multicast, and sometimes there are advantages to using stock AMI's, especially when using external monitoring and scaling services like scalr.net which preclude the knowledge of knowing IP addresses at runtime.

Perhaps a queue can be taken from the Elastic Search project which we also include in our stack. Like Hazelcast, they support multicast and static routes, but also add the option of using the Amazon EC2 instance to locate other instances in the cloud.

Is there a strategy in place for this type of node discovery?

[Talip Ozturk]

> doesn't help when we deploy to EC2. Wouldn't it be better to support 0.0.0.0
> as a binding option, especially if it is explicitly set in the config?

It is not only about binding to an IP. We already do bind to 0.0.0.0
but each node has to pick an IP that is reachable by the other nodes.
Picked IP is made part of the member list so that nodes can connect
via TCP. Now the question is how? At EC2 you should somehow have
Hazelcast pick 10.*.*.* IP. so At EC2 you should always have:
<interfaces enabled="true">
<interface>10.*.*.*</interface>
</interfaces>

> There are, of course, other issues when deploying to EC2 since there is no
> multicast, and sometimes there are advantages to using stock AMI's,
> especially when using external monitoring and scaling services like
> scalr.net which preclude the knowledge of knowing IP addresses at runtime.
> Perhaps a queue can be taken from the Elastic Search project which we also
> include in our stack. Like Hazelcast, they support multicast and static
> routes, but also add the option of using the Amazon EC2 instance to locate
> other instances in the cloud.
> Is there a strategy in place for this type of node discovery?

Yes. this is another issue. I agree that we should have more EC2
friendly discovery strategy but we don't have it yet.

-talip