I have found out what I was doing wrong.
In my example I did not explicitly set the Endpoint for the receivers.
So they got the component id as endpoint name.
When then one endpoint was stopped it could happen that the sender still
tried to reach this endpoint. A snyc send then blocked.
When I restarted the receiver it got another endpoint name and was not
able to receive the message. So I thought the handling of failover
was somehow broken in servicemix.
Now I explicitly set my endpoint name to JBI and the failover and load
balancing works.
Still it is not perfect that endpoints are never deleted but with named
endpoints there are no bigger problems with this.
In any case I think my setup would make an interesting example for
failover. None of the standard examples in servicemix showed load
balancing and failover.
Best regards
Christian
Guillaume Nodet schrieb:
That's the base asumption for ServiceMix clustering.
A JBI endpoint is uniquely identified by its service QName and
endpoint name.
When two JBI endpoints are activated in two different nodes in the
cluster
(this is not possible in the same node), it is considered as the same
JBI endpoint,
so that requests will be load-balanced between both nodes in the cluster.
That's the reason why a single JBI endpoint may have a local
implementation
and 0 or more remote implementations.
When a node goes down, the jms and jca flows receive the message
RemoveInfo.
All remote endpoints for this node should be removed from the
InternalEndpoint
remote map.
On 11/20/06, Christian Schneider <[EMAIL PROTECTED]> wrote:
I will try to create a patch but I need some more information to do it
right.
Reading the sources I am not so sure what exactly service and endpoint
mean. Could you define the two terms for me or point me to some external
docs.
from the JBI spec I presumed the following:
- a service would is an implementation of a service interface
- an endpoint is the concrete instance of a service that resides in a
given container
In the sources an internal endpoint has a map of remotes. So it seems
that an endpoint is not really exactly one service instance?!
Christian
Guillaume Nodet schrieb:
> 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
>>
>>
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
--
Christian Schneider
---
http://www.liquid-reality.de
