The only way you won't see the V3 process running after a failed startup
is if the JVM itself flames out. E.g.
asadmin start-domain --debug
asadmin start-domain --debug <flames out -- Debugger won't allow 2
processes to use the same port>
If you, say, add garbage to domain.xml, then no modules will be loaded
or running BUT the process will be running. IMHO this ought to be a
fatal error with a clean process exit.
start-domain will eventually report that the domain failed to start but
the process will be running forever until you manually kill it
(stop-domain can't reach it).
----------------------------------------------------------------------
What 'asadmin start-domain' does is this:
start the domain
Send a "version" command to the admin port for that domain. When a
response is given -- the domain is started.
(There is no "are you running" API, so this is what I dreamed up before
for the meantime)
Note that if you start the same domain twice -- both start-domain calls
will report success. The second start will report success instantly.
That's because we are contacting a port -- not a process
------------------------
Right now we have defined successful start as the ability to handle
request/response of remote admin commands.
A simple addition to asadmin would prevent the same domain from be
started more than once -- asadmin simply runs the "version" command
BEFORE trying to start a domain. If a response is received it would
fail out.
This would be a fine solution for asadmin in any case to make it more
robust. But the onus ought to be on V3 itself. V3 should be aware that
it is already running and refuse to launch another copy of itself.
Jerome Dochez wrote:
> I agree, I think it would be very easy to add.
>
> I have some ideas on how to do that, any taker ?
>
> jerome
>
> On Jun 24, 2008, at 4:29 PM, vince kraemer wrote:
>
>> Hmmm....
>>
>> The lack of a clear definition of 'successful startup' sounds like a
>> major design issue that needs to be addressed pretty quickly.
>>
>> I would think that a container init failure is a clear indication
>> that they server did not start successfully...
>>
>> The module system is like the starter motor on your car... few
>> people think that hearing it spin indicates that the car has started
>> successfully...
>>
>> vbk
>>
>> Lloyd L Chambers wrote:
>>
>>> Peter,
>>>
>>> My understanding is that the V3 system is so module-based that
>>> failure of a particular module doesn't necessarily mean that
>>> startup was "unsuccessful". In V2, the code "knew" that failure of
>>> certain containers was fatal (some of the time at least, there are
>>> clear bugs in that area even in V2).
>>>
>>> AFAIK in V3 we currently lack semantics of what "successful
>>> startup" actually means:
>>> - there is no "failure is fatal" flag (AFAIK) for a module, and
>>> it's not clear that we should have such a flag;
>>> - success could be multi-state: failed, started with errors,
>>> started cleanly, etc.
>>>
>>> Perhaps there should be some kind of pluggable listener service
>>> that could make the decision as to whether a failure should be
>>> considered fatal.
>>>
>>> Lloyd
>>>
>>> On Jun 24, 2008, at 10:43 AM, Peter Williams wrote:
>>>
>>>> If I have two default installations of V3 TP2, I can start both of
>>>> them via "asadmin start-domain". As expected, the first instance
>>>> is fine. The second one has 3 bind exceptions in the log (shown
>>>> below) but according to asadmin, start-domain was successful. The
>>>> second process appears to be running (but is not the recipient of
>>>> http calls on port 8080 - the first server instance gets those).
>>>>
>>>> Bug or Feature?
>>>>
>>>> Tail of log for second instance...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.