Jerome Dochez wrote:
> Ok but then u end up blocking everyone.
Not sure I understand why you would block everyone. You will block only
the asadmin commands that cannot yet be executed for some reason.
How can you discriminate
> applications at the Tcp level before loading at least the deployment
> actifacts ?
Yes. Grizzly ARP just need a matching 'token' to use when a TCP request
comes in. So if we say that all requests that matches 'XXX-ttt&A=B'
cannot yet be executed, ARP will suspend the request, release the thread
and resume the request only when some 'external' services notify ARP
that they can now serve the request. This is what the open-esb/httpbc
use since v1 and it seems to work fine :-). I suspect we can do the same
for v3 at tcp/udp/tls level.
A+
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>