Jerome Dochez wrote:
>
> 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 ?
It looks at the "exit code". Isn't that a standard
while writing scripts?
>
> 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 ;-)
And the problems were ...
>
> 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.
Hmmm, if you think it is not possible to predict it (i.e.
there is a technical limitation to it), then why doesn't
server startup wait till it's fully functional *by default* and
ready to go, rather than having the admin user say
start-domain --wait-for-completion=true?
BTW, how does the tools-plugin do it? It's not going
to invoke "asadmin start-domain --wait-for-completion=true",
right?
>
>
>>
>>
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>