[ http://jira.jboss.com/jira/browse/JGRP-28?page=comments#action_12315012 ]
Bela Ban commented on JGRP-28:
--
[Lez Haslewoord]
We don't want to use the bind.address property, as it sets that value for the
entire VM and all components that reference it (i.e. clustering for
DefaultPartition, Tomcat-Cluster, etc).
The client requirement is to run JBoss in clustering mode at all times, but
only have a node join the group when desired. When testing, the developers
just want to bind to the localhost to ensure the mcast packets aren't sent to
other members on the network, thereby preventing an undesireable group
membership. The only change needed to go to production would be to change the
bind address to the default (eth0) ip/interface.
Given the following UDP stack config on 2 separate machines (or 2 jboss
instances on the same machine):
we verified the following w/ ethereal on a 3rd machine in the same network
(this machine isn't running JBoss - we're just using it as a network sniffer):
1. During startup of node 1 and node 2, no JGroups UDP packets originating
from either host are being sent on the network. (so far, so good)
2. Long after both nodes have started up, no JGroups UDP packets originating
from either host are being sent on the network. (still good)
3. If either node shuts down their JBoss instance, 1 and only 1 JGroups UDP
packet originating from that node is being sent to the network during shutdown.
(not so good).
This means that packet was not swallowed by the loopback interface, and intead
it was sent via the default interface (eth0), even though we've explicitly
configured the UDP stack to _not_ do that.
I'm not sure why that 1 packet would be sent (maybe its related to broadcasting
a member leave event?). The concern in this case is that we don't want other
machines on the network to receive that packet, implying that other nodes do
exist. If it _is_ a leave event, the other members would probably ignore it
since the node that sent it was never part of their group to begin with. That
may be the case, but it would be nice to know why this packet ever goes to the
network on the default interface, instead of being swallowed by the loopback
interface as it should have been.
> Remove sendDummyPacket() in UDP
> ---
>
> Key: JGRP-28
> URL: http://jira.jboss.com/jira/browse/JGRP-28
> Project: JGroups
> Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 2.2.8
>
> Original Estimate: 2 hours
> Remaining: 2 hours
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
