Kedar Mhaswade wrote:
> Hi Tony,
> I am not an expert on deployment, but believe that deployment is a
> special case, especially when it is the standard JSR 88 way. The
> client has to provide the so-called Status
> <http://java.sun.com/j2ee/1.4/docs/api/javax/enterprise/deploy/spi/status/ProgressObject.html>of
> the deployment process(es). One of the ways to attempt to provide the
> status is to poll the backend MBeans for the same. Every such polling
> operation essentially is an MBean-method-invocation which determines
> the status of a deployment request issued previously. Now, we can
> either fake the status, increase the polling interval or make it a
> blocking call so that the status is either 0% or 100%.
Forget the increased polling interval, it would make deployment slower.
We could do the blocking thing but it should be an implementation detail
of the AMX depending which connector is being used. Do you know how much
time is lost due to this polling ?
>
> Does anyone know how other "JSR88 (or J2EE 1.4) compliant"
> application servers get around this problem? Or they don't care about
> the status, progress-objects etc.,?
I am sure they do care about the progress objects, they may use two way
protocols and be only called when something happens, avoiding this
polling exercise.
jerome
>
>
> Thanks,
> Kedar
>
> Tony Ng wrote:
>
>>
>>
>> Can we find a way to optimize the number of MBean method invocations
>> for deployment? Doing 27 calls for a simple deploy command just seem
>> excessive.
>>
>> Thanks,
>> Tony
>>
>>> Jan,
>>> You are right in that a new HTTP Connection is created with every
>>> "remote" request to the admin server. The idea of a session for time
>>> consuming CLI operations that usually result in multiple HTTP calls
>>> to the backend (e.g. deployment) is something that we should
>>> definitely try to optimize.
>>> The way CLI currently communicates with the server is based
>>> loosely on JSR 160 specification. In other words following generally
>>> holds:
>>>
>>> - CLI operation = one or more MBean method invocations.
>>> - Every MBean method invocation = A new HTTP Connection.
>>>
>>> Thus a CLI operation that results in multiple operations on MBean is
>>> treated same as two CLI operations resulting in two or more MBean
>>> method invocations.
>>>
>>> Since every CLI operation invokes a VM, we definitely can not do
>>> much session-wise, across CLI invocations, but for more time
>>> consuming operations we can definitely make client side look at the
>>> HTTPServletResponse that it received from the server and send the
>>> same ssoid for subsequent method invocation. In general, this could
>>> always be done safely, right?
>>>
>>> Something that should be noted here is that the notion of HTTP
>>> Session is not built into CLI implementation of HTTP/JMX Connector
>>> and we should correct it wherever possible.
>>>
>>> Nandini/I will work with you on this and if we can not do it
>>> (looking at the response and ssoid), we should turn off the SSO on
>>> virtual server, __asadmin.
>>>
>>> Thanks for your comments,
>>>
>>> Kedar
>>>
>>>
>>> Jan Luehe wrote:
>>>
>>>> I made the observation that using the CLI (on PE), which
>>>> uses BASIC authentication, each and every HTTP request forces the
>>>> client to be reauthenticated on the server. For this to work, each
>>>> HTTP request from the CLI carries an "Authorization" header with some
>>>> prefabricated credentials, computed from the admin's name and
>>>> password, in order to avoid the "WWW-Authenticate" challenge from the
>>>> server.
>>>>
>>>> This overhead gets worse by the fact that SSO is turned on by default,
>>>> meaning that each time the client has been authenticated, an SSO entry
>>>> is created for the authenticated principal. I measured that for the
>>>> deployment of a single WAR file (via "asadmin deploy"), a total of
>>>> 27 (!) SSO entries were created, each carrying the same authenticated
>>>> principal. Each SSO entry is stored in a map and keyed by its "ssoid",
>>>> a random number that is returned in the response (as the value of the
>>>> SSO cookie). This means that for each of the 27 identical SSO entries,
>>>> 27 random numbers had to be generated - during a single "asadmin
>>>> deploy"
>>>> command, and for no use.
>>>>
>>>> All SSO entries will eventually be purged (their max-inactive-interval
>>>> defaults to 5 minutes), but they should not be created in the first
>>>> place (or only one should be created and reused).
>>>>
>>>> We could avoid this overhead by having the server component that
>>>> processes the request create an HTTP session, which would cause the
>>>> web container to store the authenticated principal in that session and
>>>> avoid unnecessary reauthentications on subsequent requests. This would
>>>> require the CLI to include the session id in subsequent requests.
>>>>
>>>> If we don't want to create any sessions on the server, the CLI could
>>>> include the SSO id (received in the response) in subsequent requests,
>>>> which will also avoid unneccessary authentications on those requests.
>>>>
>>>> I'm not at all familiar with how the CLI currently processes the HTTP
>>>> responses from the server, and if it is capable of processing
>>>> session or
>>>> SSO ids, but it's something we need to investigate (unless this is a
>>>> known issue). If this turns out to be impossible, we should at least
>>>> consider turning off SSO on the "__asadmin" virtual server.
>>>>
>>>> Please let me know what you think.
>>>>
>>>>
>>>> Jan
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>