NamingContext dependencies

[jerrygauth]

JBAS-2957 prescribes the use of JGroups for AutoDiscovery, replacing the existing sockets implementation. This will require that the AutoDiscovery clients use JGroups classes, either directly or indirectly.

Currently the only AutoDiscovery client is org.jnp.interfaces.NamingContext. Since the naming service is included in non-HA environments, it seems likely that we don't want to introduce HA/JGroups dependencies on NamingContext. Consequently it will be necessary to use reflection to incorporate the necessary replacement code into this class.

Any alternatives or concerns about this approach?

[adrian.brock]

Use an abstraction. Then one possible implementation is JGroups.

[jerrygauth]

OK - so here's roughly how I'll proceed.

1) The simplest solution would be to add JGroups code to directly replace the mutlicast code in the two classes affected: NamingContext and DetachedHANamingService. This would obviously bind the communication mechanism to JGroups. Probably more importantly, it would introduce compile and runtime dependencies on JGroups to the Naming module. Currently this module has no dependencies on any JBoss modules (compile time at least) other than itself. So this option will not be implemented.

2) The less intrusive solution would be to introduce some type of discovery abstraction to the naming module. A simple solution would be to add a "Discovery" interface to the naming module (e.g., org.jnp.interfaces.Discovery). This interface might only provide a single method - getDiscoveryAddress(). The NamingContext instance would dynamically instantiate a "discovery provider" and invoke the getDiscoveryAddress method. This would leave compile time dependencies as is and runtime dependencies would be unaffected in non-ha environments (e.g., the default server environment). The instance might be defined as an environmental property (e.g., jnp.discoveryProvider=org.jboss.ha.jndi.HADiscoveryProvder).

The JGroups-based discovery provider would be added to a different JBoss module, presumably the cluster module. This provider would be loaded on the server by the DetachedHANamingService, as is currently done.

At runtime, a standalone client desiring discovery services would need to add the JGroups jar and the hajndi jar to their classpath.

JGroups could be swapped out by configuring a non-JGroups alternative. Note that the intent of JBAS-2957 is to replace the existing implementation so it wouldn't be provided as an alternative.

Thoughts?

[brian.stansberry]

1) I think we'd discussed porting this to Branch_4_0, but now that I see what's involved, I don't think that's advisable. Existing clients won't have the jars on their classpath, and I don't think we should make them add them for a point release.

2) One of the key advantages JBCLUSTER-43 lists for the JGroups-based approach is that "different discovery mechanisms are available: IP multicast, TCP, GOSSIP etc". How would each of these be configured (both on the client and server sides)?

3) What does getDiscoveryAddress() return? The name makes me think it would be the multicast address used for discovery, but I think what you'd really want it to return would be the IPAddress/port of the discovered HA-JNDI server.

[jerrygauth]

1) Agreed

2) For testing, I'm just using a bare-bones stack provided by Bela. If we want to make this configurable, we'll probably have to expose an AutoDiscovery JGroups stack in the cluster config file (similar to how the AutoDiscoveryAddrss and Port are now exposed). I think the NamingContext client can access this configuration in a cluster environment so it can probably pass the configuration to a constructor. Then we can ensure that client and server use the same stack. We could also expose the client stack in the jndi properties file (e.g., jnpDiscoveryStack) bu this would probably be more error-prone.

3) Correct - what's being returned is the IPAddress/port of the discovered HA-JNDI server. Maybe a more aptly-named method would be appropriate.

[starksm64]

No new code should be created in the org.jnp.* package namespace. I'm in the process of moving the server module org.jboss.naming code into the naming module. All new naming related code should be under org.jboss.naming.

[jerrygauth]

ok - so it will be org.jboss.naming.NamingDiscovery.getHaJndiServer(), located in the 5.0 naming module.

[jerrygauth]

I've abstracted the NamingDiscovery client so that it's not bound to JGroups (i.e., the Naming Service instantiates a Naming Discovery client and asks it for the identity of a discovery server).

On the server side, the implementation being replaced is an inner class in DetachedHANamingService. Any thoughts on whether this should also be abstracted out? Note that DetachedHANamingService and other HA classes already use JGroups directly so the HA service is alrteady bound to JGroups.

I can abstract out the server implementation (which needs to implement Runnable and return the ha-jndi server address) or I can simply replace the existing inner class's socket code with JGroups code. My working prototype uses the latter approach.

[belaban]

Make sure this works with the Multiplexer, when it is available.

[brian.stansberry]

I just realized that the jgroups dependency also introduces a commons-logging dependency to the client side. Not the end of the world, but not so nice either.