On Feb 27, 2008, at 11:44 AM, Jeanfrancois Arcand wrote:
>
>
> 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.
>> 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.
>
>
> I agree with Kedar about blocking. I've already a task to implement
> suspendable/resumable requests (Comet). What you are describing here
> is exactly what we need, e.g. suspend the request until the app is
> ready, and resume once we are ready.
which is what I want for admin gui
but there is more to life than web ;-)
>
>
> A+
>
> -- Jeanfrancois
>
>
>
>>>
>>> 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
>