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.
We currently have a bug to track the issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6306606
For a reason that needs to be investigated, the number of call on
windows is 3 times higher.
-- Jeanfrancois
>
> 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
>
>