OKAY. Here it goes.
Prerequisites.
(tested on 1.5.2 problems on
1.4.5)
A. Setting up the
cluster.
A.1. RMI.XML:
A.1.1
EXPLICITLY bind to the machine's IP
<rmi-server
host="<machine_ip_or_adress>">
A.1.2 SAME cluster
configuration on all machines
<cluster
username="clusteruser" password="clusterpass"/>
If you want
you can use a nonstandard MCast IP and Port,
but it HAS TO BE
the same for all machines
A.2. Application
set-up.
One and the same
Application name for the clustered app.
Like this in
server.xml (on all machines):
<application name="Cluster" path="../applications/Cluster"
/>
Deployment source
doesn't count. The NAME HAS TO BE THE SAME.
B. Tips for correct
working.
B.1. This is NOT
full cluster:
B.1.1 An EJB is searched on othe machines if it is not
present
on the
current one. If Machine A has bean BeanA any other bean,
trying to
access BeanA will be used from this machine only.
B.1.2 Once
you get a reference to a bean you will not get a
reference to the same bean on another
machine. If Machine A
does not
have BeanA and wants to use it, it will look it up
on the
cluster and use the LAST ONE, that has been found (i.e
if MachineC
has been the last to boot-up and has BeanA, then
machine A
will use the bean from Machine C.
B.1.P.S. I hope this will be fixed soon.
B.2. Deploy your entity beans
in one place only. Do so with
your stateful session beans
also.
C. Additional
info.
C.1 JMS. One can
use the JMS server on one machine. This way
anyone
looking for a QUEUE or TOPIC will find it on that one.
EX. in
jms.xml:
<queue-connection-factory host="192.168.2.111"
port="9129"
username="admin" password="123"
location="jms/QueueConnectionFactory" />
<topic-connection-factory host="192.168.2.111" port="9129"
username="admin" password="123"
location="jms/TopicConnectionFactory"
/>
TRADE OFF:
When the JMS server machine shuts down and boots up.
Every
other machine has to be
restarted in order to reregister
the QUEUE
and TOPIC
clients.
PLUSES:
MDBs are synchronized. Keep in mind the JMS technology
a
TOPIC message is received on all machines. A QUEUE message
is
received by
only one. However that means, that in most cases (but
not always)
the QUEUE message will be received by one and the
same
client.
P.S. There is
still quite some job to be done on the clustering,
but for now this is
more than nothing. Personally I'll have to
create my own execution
scheduler, that will be responsible for
round-robin execution
of my clustered SLSBs.
Well... Not much, but
at least works :(
Lachezar
