This is too big of a change in behavior to implement in the community 4.x series or in EAP 4.x.
It's also too big of a change to make for 5.x, as such a large change would have to go in 5.0.0 and it's too late in the release process to do that.. Not that I want to, as there is a valid workaround, one which involves a best practice anway.
I could consider the change for AS 6, but would need to be convinced that the workaround is inadequate and the potential disruption is justified.
The workaround for AS 5 is, as you said, to use -u to assign a distinct multicast address to each cluster. This is a best practice, regardless of this HA-JNDI issue. Doing this will prevent server nodes responding to discovery packets from clients not specifically configured to use the correct multicast address via the jnp.discoveryGroup naming environment property.
That same solution can be used in AS 4.x and EAP 4.x as well, although it is less reliable due to the "PromiscuousTraffic" problem discussed at http://www.jboss.org/community/docs/DOC-11710. AS 5.0.0.GA will include a fix for that problem in the HA-JNDI service.
Another solution is to change the HA-JNDI service's "AutoDiscoveryGroup" config from the default 1102, using a different value in each cluster. Then configure clients to use the correct port via the jnp.discoveryPort naming environment property.
A third solution is, of course, to turn off autodiscovery on the server side via the HA-JNDI "DiscoveryDisabled" property.
The -u solution though is the one that comes closest to "working out of the box" as it involves no config file changes.
anonymous wrote : * Use of the -g run.bat/run.sh command line argument as the client will only accept replies from "DefaultPartition" clusters by default.
This workaround won't work, as that's not the way autodiscovery is handled. If on the client side you configure jnp.partitionName, that value is included in the auto discovery packet. If not configured, no name is included. It's on the server-side that the validation check is performed, and the absence of a name is treated as a wildcard, i.e. a response is returned. So, to take advantage of -g to prevent invalid responses, jnp.partitionName would have to be configured on the client side.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185842#4185842
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185842
It's been requested that in future JBoss releases, the use of auto-discovery by clients be disabled by default. JBAS-6089  captures this feature request, and this forum thread is for capturing the discussion surrounding this JIRA.
Essentially, in the cases where the provided JNDI URL isn't available, auto-discovery can cause unexpected behavior as it is possible to connect to clusters that have nothing to do with the client.
Potential workarounds are:
* Use of the -g run.bat/run.sh command line argument as the client will only accept replies from "DefaultPartition" clusters by default.
* Use of -u run.bat/run.sh command line argument as this causes the auto-discovery service to listen to the specified multicast address rather than the default so it won't get the client request in the first place.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185832#4185832
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185832