Ok but then u end up blocking everyone. How can you discriminate
applications at the Tcp level before loading at least the deployment
actifacts ?
Jerome
On Feb 27, 2008, at 11:57 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM
> wrote:
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>