On Aug 24, 2007, at 6:44 PM, Bruce Snyder wrote:

On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:

On the registry side, I think one of the main problem is that there
is no way to tell the
difference between an endpoint that goes down because the server is
no more
accessibe (it will be up again at a later time) or because the
endpoint has been
undeployed.  Imho, this is a key requirement to be able to make
routing decisions.
I don't know yet how to handle this problem:  if a server has been
shutdown, it may
never go up again... So i'm still not sure how to handle the problem :-(

This is one place where a proper registry might be useful. If the
registry handles metadata for a given component, it can provide this
type of finer grained information to anyone that is interested. E.g.,
if a component is undeployed, the deployer tells the registry that
componentX is being undeployed and the registry would store that
information. When componentX comes back online it tells the registry
and the registry updates the metadata.


I agree, but it may not even be sufficient. Let's take the example of Kit.
This environment is very dynamic and instances will not even say
that the endpoints are undeployed.  They are just gone and may never
appear again.  Another example: if you use a cluster of servers and you
want to bring one down, will you really undeploy everything or just shut
ServiceMix down ?

So I'm not sure you can really know wether a service will come up at a
later time.  This requires much more knowledge that ServiceMix can
have.  I guess we could have a default behavior that would say when a
server goes down if the endpoints should be considered temporarily
unavailable or permanently lost.

We currently don't have such a feature in the JMS/JCA flows, but we
definitely need something around that...

Cheers,
Guillaume Nodet

Reply via email to