Jerome Dochez wrote:
>
> 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 ;-)
Right, but the feature is at the TCP level, so not only with HTTP ;-)
-- Jeanfrancois
>
>>
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>