[jerrygauth]

I think the plan was to only implement this in 5.0. It could be backported to 4.0 and the original implementation could be provided as the default with the JGroups based implementation as the alternate. But this would seem to defeat the stated purpose of JBCLUSTER-43/JBAS-2957 as it would then be necessary to maintain multiple AutoDiscovery implementations.

[starksm64]

This issue really seems to be too much of an island to be useful. Naming in jboss5 should be using the remoting framework for proxies, and in turn the remoting locator services. The JBAS-2957 issue should really be an implementation supported by the remoting locator. I'll send Tom Elrod over.

[brian.stansberry]

Bela, Tom and I are having a general roadmap discussion with Tom on Friday; this was on the agenda.

[tom.elrod]

My preference is to have a centralized component for discovery that all the projects can use. I don't really care where that lives, but since is probably most often related to clustering, that project would be a good choice.

The major requirements for the discovery component would be that has a generic API (so metadata for what types of components disovered can be passed through and not directly tied to any particular project/technology) and offers a few services, such as to publish a clustered components metadata and some form of callback for when the topology changes. However, the key requirement would be that the actual mechanism for doing the discovery would be pluggable (and maybe even allow multiple impls being used at any point in time). This would allow for multicast, JNDI, etc. implementations to fit different needs of different environments, but would be invisible to the higher level API.

[brian.stansberry]

I want to touch a bit on the meaning of "discovery". Much of the following may be obvious to some of you, but I find it helpful to spell it out :)

Current clustering client-side "discovery" consists of 4 pieces:

1) Initial detection of the cluster's JNDI service. This is the multicast based discovery that was the initial focus of this thread.

2) Discovery of other services. Once a JNDI server is discovered, any other desired service is located is "discovered" via a JNDI lookup, with the downloaded proxy bearing the cluster topology for the service. Only information about the topology of the *desired* service is transmitted. Information about how to access that service on *all* cluster nodes is transmitted.

3) Changes to the cluster topology for the service are subsequently "discovered" by making requests to the service and receiving piggy-backed topology changes on responses.

4) In case the cluster topology for a service is completely out of date, some services support a mechanism (RetryInterceptor) whereby step 1 is transparently retried and then the invoker (not the full proxy) for the service is looked up.

The fundamental requirements 1 and 4 are quite similar in that they just involve getting an set of InvokerLocators for a service. So, a server-side discovery service used to find the JNDI server could potentially also provide an updated set of cluster targets for any service. This discovery service could also be used by any remote client that just needed a set of targets, and had no need to download a full proxy from JNDI.

The mechanism for doing 1/4 is what we are really focusing on in this thread.

#2/3 are different, although their mechanism would need to interface with the same target registry (client-side ClusteringTargetsRepository/NetworkRegistry and server-side DRM/InvokerRegistry) used by #1/4.

[brian.stansberry]

A key consideration for the discovery service would be client-side configuration. A review of this thread highlights the issue -- for fundamental services like JNDI discovery, we need a mechanism that 1) requires no configuration, 2) also supports some very simple configuration if needed and 3) can take advantage of arbitrary and quite complex configuration if the use case calls for it.

AFAICT Remoting Discovery is based on XML configuration. That works well for the complex cases, but is too complex for the basic cases (e.g. I just want to set the multicast address and port).

So, the generic discovery service would need to expose an API allowing a configuration object (perhaps a DOM Element) to be passed in. In the case of JNDI, the NamingContext would be responsible for translating between jndi.properties and this configuration object.

[tom.elrod]

I am totally on board with this. The discovery component I mentioned would mainly be to cover 1 and 4. I think 3 is the best practice as is, since provides the best performance. I also think 2 should be the normal practice, but would be nice to allow this same type of behavior from clustering service itself, since it already houses a basic registry of clustered services/components. That way would not *have* to depend on JNDI being present.

[brian.stansberry]

Re: where the discovery service lives, I think we need to analyze the dependencies between the two projects and pick the approach that isn't going to lead to circular dependencies :)

[tom.elrod]

Again, totally agree with having different levels of configuration for discovery in the client, starting with a default multicast (no config needed at all, just built in), and then either xml or properties file for more complex configuration.

Remoting discovery, as it is now, is way too complex to expect clients to configure for simple/standard cases like JNDI discovery.

[tom.elrod]

Re: where the discovery service lives, I think we need to analyze the dependencies between the two projects and pick the approach that isn't going to lead to circular dependencies :)

My ideal would be for clustering (or at least this discovery service) to become a separate project. Then remoting would depend on that. There should be *no* dependencies on remoting (and any discovery impl in remoting would be moved to this new project or just go away all together).

[starksm64]

So, the generic discovery service would need to expose an API allowing a configuration object (perhaps a DOM Element) to be passed in. In the case of JNDI, the NamingContext would be responsible for translating between jndi.properties and this configuration object.

I have my big whacking stick out thinking of another XmlLoadable travesty being introduced. The core api should not be coupled to a format of a configuration.

[tom.elrod]

Well, there has to be some way to configure what mechanism should be used for discovery (if not using the default) If not xml, then what?

[starksm64]

The answer is always the same; anything that converts to a pojo bean. The anything is an implementation detail, not a manifest contract. If you api cannot plugin into the microcontainer via inject of the pojo, its broken.

[tom.elrod]

So you want a swing client to run the microcontainer, or just needs to also be able to also accept config via a pojo bean when being used on the server side?

[starksm64]

Be able to accept a pojo that is created from some arbitrary configuration handled by another layer. My cell phone that does not have an xml parser should be able to lookup a phone number from jndi.