-
1. Re: JBAS-6089: Disable Client Auto-Discovery By Default?
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.* 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. -
2. Re: JBAS-6089: Disable Client Auto-Discovery By Default?
There's a user that has been having issues with auto discovery being enabled by default. They had a rogue server that was responding to auto discovery requests even though it shouldn't have. Obviously, this rogue server was not using -u and clients auto discovery were finding it (clients used default jnp.discoveryPort)
I suggested this used to use jnp.DisableDiscovery but it's too big of a change for him as you'd need to change all client look up parameters or property files from which lookup properties are loaded.
The other possible solution would be to have a system property that changes the default value for DisableDiscovery for that VM. This would be different to the per initial context creation jnp.DisableDiscovery property that we have now. Thoughts? For this particular user, I think this could make it easier to disable auto discovery.
Finally note that I'm not sure we should be changing default because if we do so, we'll be annoying other customers relying on it being enabled by default. We're never gonna be able to make everyone happy with this. -
3. Re: JBAS-6089: Disable Client Auto-Discovery By Default?
Can you confirm whether this would actually be helpful with the case you're talking about? That is, if their operational requirements preclude setting the system property, there's no benefit.