Multicast does not seem to turn off even though it is disabled in configuration

[Francesco Russo]

Hi all,
I'm running Hazelcast 1.9.4.4 (also tried with 2.* versions but it
behaves the same), and I've noticed that despite my configuration
mandates multicast to be turned off, there are still active Hazelcast
threads working on multicast and UDP sockets.

Here follows a snippet of my thread-dump which proves this:
"hz.2.MulticastThread" daemon prio=10 tid=0x0a923c00 nid=0x267c
runnable [0x8e3ba000]
java.lang.Thread.State: RUNNABLE
at java.io.DataInputStream.readFully(DataInputStream.java:178)
at java.io.DataInputStream.readUTF(DataInputStream.java:592)
at java.io.DataInputStream.readUTF(DataInputStream.java:547)
at com.hazelcast.config.GroupConfig.readData(GroupConfig.java:118)
at com.hazelcast.config.Config.readData(Config.java:641)
at com.hazelcast.cluster.JoinRequest.readData(JoinRequest.java:68)
at com.hazelcast.cluster.JoinInfo.readData(JoinInfo.java:59)
at com.hazelcast.impl.MulticastService.receive(MulticastService.java:
128)
- locked <0x9ce6fe10> (a java.lang.Object)
at com.hazelcast.impl.MulticastService.run(MulticastService.java:101)
at java.lang.Thread.run(Thread.java:662)

My Spring configuration contains this among other things:

<hz:network port="${hzc.port}"
port-auto-increment="$
{hzc.portAutoIncrement}">
<hz:join>
<hz:multicast enabled="false"/>
<hz:tcp-ip enabled="true">
<hz:members>${hzc.tcpMembers}</hz:members>
</hz:tcp-ip>
</hz:join>
</hz:network>

Is this something known or a bug? I'd like to see no multicast-related
activity in the system if in my configuration I say that multicast
must be turned off.

Thanks,
Francesco

[Mehmet Dogan]

I have just tried using both Hazelcast 1.9.4 and 2.1, but had no success to reproduce this issue. 

Are you using static/default Hazelcast methods (Hazelcast.getMap(name), Hazelcast.getDefaultInstance() .. etc) in your code? Thread name (hz.2.MulticastThread) in your dump says there are at least two instances in the same JVM.

Can you please post a test case and config file to reproduce issue?

@mmdogan

--
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.

[Francesco Russo]

Hi Mehmet,
thanks for replying.

The only thing I'm using Hazelcast for is locking, hence the only
smethod I'm using is Hazelcast.getLock(aString). There is no other
interaction between my code and Hazelcast apart from this (obviously I
acquire and eventually release the returned lock as well).

I setup Hazelcast via Spring, and this is the only relevant part:
<hz:hazelcast id="salHazelcastCluster">
<hz:config>
<hz:group name="${hzc.group}" password="${hzc.pwd}"/>
<hz:properties>
<hz:property
name="hazelcast.shutdownhook.enabled">true</hz:property>

<hz:property name="hazelcast.jmx">true</hz:property>
<hz:property name="hazelcast.jmx.detailed">true</
hz:property>

<hz:property
name="hazelcast.merge.first.run.delay.seconds">
${hzc.merge.first.run.delay.seconds}
</hz:property>
<hz:property
name="hazelcast.merge.next.run.delay.seconds">
${hzc.merge.next.run.delay.seconds}
</hz:property>
<hz:property name="hazelcast.logging.type">
${hzc.logging.type}
</hz:property>
</hz:properties>

<hz:network port="${hzc.port}"
port-auto-increment="$
{hzc.portAutoIncrement}">
<hz:join>
<hz:multicast enabled="false"/>
<hz:tcp-ip enabled="true">
<hz:members>${hzc.tcpMembers}</hz:members>
</hz:tcp-ip>
</hz:join>
</hz:network>

</hz:config>
</hz:hazelcast>

<bean id="distributedLockManager"
class="com.foo.bar.HazelcastLockManager"/>

NB: port auto-increment is false.

The first bean initializes Hazelcast itself, whilst the second one is
a really simple proxy that hides the Hazelcast API:
public class HazelcastLockManager implements LockManager {

@Override
public Lock getLock(String lockId) {
return Hazelcast.getLock(lockId);
}
}

Thus, considering the system is bootstrapped via Spring using the
Hazelcast Spring-dialect, do you still consider possible to have more
than one Hazelcast instance running?

Apart from that, however, my original concern was about that multicast-
related thread being active despite my configuration.

Thanks in advance for the support,
Francesco

On Jun 5, 11:35 am, Mehmet Dogan <meh...@hazelcast.com> wrote:
> I have just tried using both Hazelcast 1.9.4 and 2.1, but had no success to
> reproduce this issue.
>
> Are you using static/default Hazelcast methods (Hazelcast.getMap(name),
> Hazelcast.getDefaultInstance() .. etc) in your code? Thread name
> (hz.2.MulticastThread) in your dump says there are at least two instances
> in the same JVM.
>
> Can you please post a test case and config file to reproduce issue?
>
> @mmdogan
>

[Talip Ozturk]

Can you try and confirm if the multicast thread problem exists in 2.1?

http://twitter.com/oztalip

[Mehmet Dogan]

As I said in previous post you should not use static methods of Hazelcast class, Hazelcast.getLock(lockId).

When you call static Hazelcast methods, a default instance is created by using default configuration.

Instead HazelcastLockManager should implement HazelcastInstanceAware interface and get lock from injected HazelcastInstance.

[Mehmet Dogan]

By why don't you inject HazelcastInstance created by Spring into your HazelcastLockManager bean?

[Francesco Russo]

Hi, thanks for the hint.
The reason why I was using that API is because it was not clear to me
that the static API would have created a brand new instance.

I'm applying the suggested changes and let you know once I've examined
the results.

Thanks!

On Jun 5, 4:19 pm, Mehmet Dogan <meh...@hazelcast.com> wrote:
> By why don't you inject HazelcastInstance created by Spring into your
> HazelcastLockManager bean?
> On Jun 5, 2012 5:49 PM, "Mehmet Dogan" <meh...@hazelcast.com> wrote:
>
>
>
>
>
>
>
> > As I said in previous post you should not use static methods of Hazelcast
> > class, Hazelcast.getLock(lockId).
>
> > When you call static Hazelcast methods, a default instance is created by
> > using default configuration.
>
> > Instead HazelcastLockManager should implement HazelcastInstanceAware
> > interface and get lock from injected HazelcastInstance.
> > On Jun 5, 2012 5:36 PM, "Talip Ozturk" <ta...@hazelcast.com> wrote:
>
> >> Can you try and confirm if the multicast thread problem exists in 2.1?
>
> >>http://twitter.com/oztalip
>

> >> On Tue, Jun 5, 2012 at 7:23 AM, Francesco Russo <f.r.u.x....@gmail.com>

[Francesco Russo]

Thanks, that just worked fine!
F

On Jun 5, 4:19 pm, Mehmet Dogan <meh...@hazelcast.com> wrote:

> By why don't you inject HazelcastInstance created by Spring into your
> HazelcastLockManager bean?
> On Jun 5, 2012 5:49 PM, "Mehmet Dogan" <meh...@hazelcast.com> wrote:
>
>
>
>
>
>
>
> > As I said in previous post you should not use static methods of Hazelcast
> > class, Hazelcast.getLock(lockId).
>
> > When you call static Hazelcast methods, a default instance is created by
> > using default configuration.
>
> > Instead HazelcastLockManager should implement HazelcastInstanceAware
> > interface and get lock from injected HazelcastInstance.
> > On Jun 5, 2012 5:36 PM, "Talip Ozturk" <ta...@hazelcast.com> wrote:
>
> >> Can you try and confirm if the multicast thread problem exists in 2.1?
>
> >>http://twitter.com/oztalip
>

> >> On Tue, Jun 5, 2012 at 7:23 AM, Francesco Russo <f.r.u.x....@gmail.com>