While this session creation request is going on, NodeA will also send back an asynchron-
ous message that contains the cluster topology. The JBoss EJB Client implementation
will take note of this topology information and will later use it to create connections to the
nodes within the cluster and route invocations to those nodes, whenever necessary.
Now let's assume that NodeA goes down and the client application subsequently invokes
on the proxy. At this stage, the JBoss EJB Client implementation will be aware of the
cluster topology; therefore, it knows that the cluster has two nodes: NodeA and NodeB .
Now when the invocation arrives, it detects that NodeA is down, so it uses a selector to
fetch a suitable node from among the cluster nodes. This exchange is shown in the follow-
If a suitable node is found, the JBoss EJB Client implementation creates a connection to
that node (in our case NodeB ) and creates an EJB receiver out of it. At the end of this pro-
cess, the invocation has now been effectively failed over to a different node within the
Search WWH ::