The benefit of not removing the endpoints is that if the remote
servicemix comes up later, the exchange will not fail. The problem
is that we can not make the difference between a servicemix which
is put down (because of a crash or temporary stop) and a service unit
which is undeployed (the endpoint will not be available at a later
time, until the SU is redeployed).
I think this could be argued and the behavior may need
to be chosen using a flag, so that endpoint can be removed
from the registry. If you can provide a patch, i'd be glad to
check it in.
On 11/19/06, Christian Schneider <[EMAIL PROTECTED]> wrote:
I have the following setup that I am evaluating for a high availability
scenario.
- 1 Sender
- 2 Receivers
each in separate servicemix containers connected by a jmsflow.
When the receivers are running and the sender comes up it gets the
endpoints of the receivers. But when then one receiver goes down the
corresponding endpoint is not deleted. So when the sender later chooses
the endpoint of the receiver that is down the message will be still sent
to this container and the sender will hang in a sync send.
I would expect that the endpoints of a container that goes down are
removed in the other containers in the cluster. I debuged the handling
of the Advisory message in jmsflow.
The removeinfo message is received in the sender but there is no code to
remove endpoints.
Am I missing something here or is this only incomplete?
Greetins
Christian
Here is the code in jmsflow:
Form JmsFlow / protected void onAdvisoryMessage(Object obj) {
} else if (obj instanceof RemoveInfo) {
ConsumerId id = (ConsumerId) ((RemoveInfo) obj).getObjectId();
subscriberSet.remove(id.getConnectionId());
removeAllPackets(id.getConnectionId());
}
--
Christian Schneider
---
http://www.liquid-reality.de
--
Cheers,
Guillaume Nodet
