On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
>
> 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.
Well, if it's gone, it's gone. That component cannot be used. I was
assuming that this status would be used to determine how to handle
messages destined for a component that is not online. E.g.:
a) componentX is marked as undeployed in the registry so it's gone and
messages should not be held for it
b) componentX is marked as stopped in the registry which means it will
be started up again at a later time, so hold messages for it until it
comes back online
This means that certain states assume certain behavior that might work
in a manner similar to a lifecycle. E.g., if a component is in the
process of being started up, messages destined for that component
should be held until the component is fully started.
> We currently don't have such a feature in the JMS/JCA flows, but we
> definitely need something around that...
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
