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%.
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.,?
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
>