On Feb 27, 2008, at 10:58 AM, Kedar Mhaswade wrote:
> Jerome Dochez wrote:
>> On Feb 27, 2008, at 9:23 AM, Vince Kraemer wrote:
>>> It sounds like a bug to me. It seems like list-applications
>>> should pause until the server is ready to provide a correct answer
>>> [one that is not going to change without the user taking some
>>> explicit action... like issuing an 'asadmin deploy' command....
>>>
>>> That would probably apply to ALL the command... not just list-
>>> applications.
>>>
>> right, I don't think we should make anything special for list-
>> applications
>> in this particular case, I think this is a bug in the
>> implementation of list-applications, it should now use the config-
>> api to get the list of applications rather than the internal
>> runtime structures we use at run time. This was the only solution
>> at the time the command was written but since Hong added the
>> domain.xml writing last week, I think it's time to switch it to use
>> the config-api which will give the correct information all the
>> time. Jane, can you take care of that ?
>> Now, this debate still has some values.... It is somehow difficult
>> for a script to know when the server has finished starting. . We
>> could block all asadmin requests until all deployed applications
>> have finished loading but that seems like a hammer solution, and
>> even then you still need to issue a command to figure out the
>> server is fully loaded (and which one, asadmin version ????).
>>> Otherwise, folks that need to do things like automate things using
>>> asadmin will have to litter their scripts with sleep calls... and
>>> even then, the scripts may fail when moved from machine to machine
>>> because of things like processor horsepower...
>>>
>> no, worse case we would have to add an explicit command to wait for
>> server starting sequence completion.
>> It seems that it could be useful to have a blocking command like :
>> asadmin wait-startup-completed
>> that would block until the server is fully started and all deployed
>> and enabled applications are now capable of answering requests. I
>> don't think we have that today...
>> what do people feel ?
>
> I think having an asadmin command to block till
> server has started is awkward, at best. This is because
> when server displays it's started it means it's ready
> to go.
and how can a script check what the server displays ?
alternatively we could just add an option to the start-domain command,
like --wait-for-completion so that we do that as part of the start-
domain command (I like that better than the dedicated command actually).
>
>
> Can something be done so that when the *first request* for
> any app (or its component) that's deployed is sent,
> the app initialization completes and the response is blocked
> till that happens?
>
> That way, server can return as soon as possible and
> first request to any app loads the app fully.
>
> Something similar was done in V2, IIRC.
oh yes and we have seen how well that worked ;-)
in general, it's very difficult to "predicts" all entry points of an
application, some may be just a context root, some others may be web +
ejb + web services + jms, well you name it...
so this concept of blocking just does not work.
>
>
>> Jerome
>>> vbk
>>>
>>> Jane Young wrote:
>>>> Hi Anissa,
>>>>
>>>> Do you still see this issue?
>>>> The application is there but it does not get displayed with list-
>>>> applications command right after server restart. You need to
>>>> wait for a few seconds and try list-applications again and the
>>>> deployed applications are displayed.
>>>>
>>>> Jane
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>