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
>
>
>