[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBoss server mcast socket bound to network interface

[bstansberry@jboss.com]

Thanks for opening this thread, Alex.  Your interface binding suggestion has implications for end users, so I wanted it discussed here rather than in the more narrowly-read QA forum.

For background on issues QA is having, see http://jira.jboss.com/jira/browse/JBAS-4939 
and 
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123056 .

On this thread I'd just like to focus on whether having the -b switch *not* set system property jgroups.bind_address makes sense from the viewpoint of AS users, not AS testers.  If a solution doesn't make sense for users, it's not right to do it; the testsuite should just find workarounds. We can sort any testsuite workarounds on the QA forum thread.

Reasons why I don't like the idea of -b not setting system property jgroups.bind_address:

1) All other service bindings in the AS are controlled by -b.  Having an exception for JGroups is confusing.

2) If you don't tell JGroups what address to bind to, it will bind to the first non-loopback interface it finds when iterating over NetworkInterface.getNetworkInterfaces().  So, not clear that will be the desired interface. Even if JGroups or the AS were changed to pick the machine's default interface, it's not certain that would be the interface that supports multicast either.

3) This would be a significant change in behavior from previous releases, so we would have to spend significant effort educating users/SEs/consultants, altering docs, wikis, training course materials and certification exams etc.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102252#4102252

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102252