geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee" <>
Subject Re: Is there a caching order problem with authentication challenges?
Date Fri, 18 Jan 2008 17:47:54 GMT
Yeah, I think caching the session before calling sendRequest() is a slightly
better idea.  I don't think it's a major difference however.
The difference would be noticed only if the current connection is the *only*
active connection to the host.  If there are more active connections for the
given host, the subsequent sendRequest() call will happily pick up the
connection that's at the front of the queue and start.  Note the session
cache employs a queue, so the behavior is FIFO.  But I do agree that in the
case described above, caching it before sendRequest() would work better.


On Jan 18, 2008 7:39 AM, Rick McGuire <> wrote:

> While working through the code looking to add hooks for signaling the
> monitoring events, I noticed the following bit of code in the
> ResponseFuture:
>            //Authenticate
>            int authCount = request.getAuthCount() + 1;
>            if (authCount <= 3) {
>                request.setAuthCount(authCount);
>                client.sendRequest(request);
>                // if we've been provided with a cache, put this session
> into
>                // the cache.
>                SessionCache cache = getSessionCache();
>                if (cache != null) {
>                    // cache the session before we return
>                    cache.cacheSession(ioSession);
>                }
>                return;
>            }
> This is sending the challenge response back to the server, but returning
> the connection to the cache AFTER the request is sent back.  Shouldn't
> the connection be returned to the cache BEFORE the challenge response is
> sent to allow the connection to be reused?
> Rick

View raw message