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
>