geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: GeronimoMBeanTarget.doStart() - failure mode ?
Date Sat, 03 Jan 2004 00:15:38 GMT
On Jan 2, 2004, at 4:13 PM, Jules Gosnell wrote:

> David Jencks wrote:
>
>> When converting AbstractManagedObject thingies to GeronimoMBeans I 
>> have generally ignored this advice and simply thrown a 
>> RuntimeException.
>
> i thought of that, but I think you would agree that it is not the best 
> solution :-(

Not a good idea.  Then you move to the failed state which requires an 
admin to fix.

>> I think that perhaps it's reasonable to check internal consistency in 
>> canStart but not do anything that queries the outside world.  I would 
>> prefer an explicit "CantStart" exception in the signature of Start.  
>> For instance, if you are opening a server socket, you'd have to open 
>> it in canStart and leave it open to guarantee that it will still be  
>> available in Start.  AFAIK this won't work if later you decide not to 
>> start:-)
>
> Agreed,
>
> Internal consistency can be checked in canStart(), but anything 
> relying on the external world in doStart() cannot be tested, unless 
> you lock the whole external world between the canStart() and doStart() 
> methods...
>
> Forunately, the particular case that is troubling me now is one of 
> internal consistency...

This is a big problem.  Especially, when you get into multi object 
GeronimoMBeans, which is why we have canStart.  The issue is once you 
have decided you can start, we go through each bean and call doStart, 
which will interact with the external world (like creating sockets).  
If one of the objects in the GeronimoMBeans throws an exception, we 
have no reliable way to rollback the system to a "starting" state, so 
the component fails.  I actually think that having the web service move 
to failed when the socket is in use is the correct outcome.

-dain


Mime
View raw message