New Members joining a cluster and remote stubs etc.

[tallpsmith]

Firstly hats off to you for an impressive product, both Jboss 2.4 and v3 have worked first time out of the box. Don't see that often today. Secondly, hats off again for the excellent documentation. wow.

Okay, the question. Can someone explain a little about how the remote stub retrieved from JNDI by a client is notified, or understands that a new member has joined the cluster? I am assuming the smarts are in the stub, but maybe not..

e.g.

1. Server 1 starts up as the first to join DefaultPartition

2. Client 1 does lookup and gets the stub/home/remote for EJB 'MyEJB', and does some work

3. Server 2 and 3 join the cluster

4. Client 1 decides to do some more work with 'MyEJB'.

At this point how does the stub on Client 1 know that there are 2 more members that can service the request?

If this is in the docs and I just missed it or misunderstood the significance, just point me to a page reference to the JBossCMP.pdf and I'll read it again.

cheers, and thanks again.

Paul

[tallpsmith]

and I mean JBossClustering.pdf! :-) ... doh (was reading that at the time...)

[belaban]

I believe what happens is the following:

- The cluster consists of 1 server
- Now 2 additional servers are started
- At this point you invoke a method on MyEjb. At this point the membership (3 servers) is piggybacked on the RMI response to your HA proxy
- Now the proxy know that there are 3 servers available from which to choose
- The HA proxy won't know about the updated membership until it invokes a method on the bean
Bela

[slaboure]

Yes, Bela got it perfectly right! ;)

The invocation sent to JBoss and the answer that come back are actually wrapped in some kind of "meta-invocation" that is able to carry more information. Consequently, if, and only if, the topology has changed, we send an updated view of the cluster with the result of the invocation. If no call is performed on a node, the client will not get a refreshed view of the cluster.

In the alpha code for SLSB that I did, some asynchronous view-refresh of the cluster topology was done. I think that actual scheme is much better.

Cheers,


Sacha