Niclas Hedhman wrote:
On Saturday 15 March 2003 09:12, sadaf zargeen wrote:
I know I can declare service(block) dependencies for my applicaiton in the assembly.xml.
This I assume ensures that if e.g block A is dependent on another block B, and that block B is dependent on block C then block C is started and deployed followed by block B followed by block A.
My question is that if for whatever reason, block C is
brought off line (shutdown/disabled/etc), does
phoenix and avalon framework detect and automatically
take off-line block B followed by block A ?
Slight correction, should be the reverse order of the start sequence; Block A should be stopped first, then B then C...
subsequently if block C comes back on line, would blocks B and A be restarted in the container again ?
This is so that an application automatically detects
when a service it depends on is gone offline and
therefore stops servicing requests. and vice versa.
I would also like to know the answer...
The problem I've found here is not so much the question concerning orderly decommissioning of a failed component, but much more of a case of fault determination. In effect what a container needs is a mechanisms whereby a component can notify a container of a fault condition following which the container can initiate decommissioning (include disassembly). Another fail scenario is a component that is simply not responding (deadlock for example). This requires some mechanisms whereby a container can periodically poll a component for a response. In the case of non-response the container can undertake the orderly decommissioning of the component (but this has its own related problems - i.e. you cannot interact with the object but you can decommission the components that is it supplying services to).
Failure notification could be active (component notifies container of fail condition) or passive (container periodically checks component). If the component is running in a thread its possible for the container to trigger decommissioning automatically following thread termination.
Restarting (or redeployment) of components is relatively unexplored area. In the example above the decommissioning of component C should result in either decommissioning or suspension of components B and A. A container can re-establish C, however, resumption of B and A must occur in such a way that B picks up a new reference to A. When the object reference C changes, all components dependent on C have to be re-serviced, whereas an object such as A does not - A only needs to be suspended during the process and resumed at the end.
However, there is a problem here. The container has no way of knowing if component B has supplied a reference to C to component A. So at the end of the day, the most reliable and predictable solution is to decommission the entire tree following by a clean re-deployment.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
