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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...