Hi Menelaos, My understanding is that most web servers using HTTP keep-alive will dedicate only one thread per request, unless the application developer explicitly creates new worker threads to delegate to (and Shiro has a facility for this scenario). Once the socket connection terminates and a new request is made then obviously there is no guarantee that the same thread will be used (likely not), but in the case of Shiro as long as the session information is sent with each new request then whatever Subject instance is returned does not matter because it will be logged in as that user anyway.
My use case does not involve HTTP or a web container, so it is irrelevant to me, but still interesting to understand how it works. I believe that the best bet for my situation (multiple Subjects on one thread - bound to the Netty Channel instead of a ThreadLocal) is to build my own data structure and use it to hold onto Subject instances for the course of each Netty Channel lifetime (which has its own lifecycle observer interface). This would closely mimic the behavior of the default implementation, only for an NIO-based server instead of a thread pool based one, at least as I understand it. I will post additional updates as I continue to experiment with this approach in my free time. Best, David On Wednesday, November 28, 2012 at 6:12 AM, Menelaos Perdikeas wrote: > Actually I was looking at the implementation of ThreadContext#getSubject > today (which is what SecurityUtils#getSubject > calls). > > It seems that ultimately getting the right subject is hinged on having a > separate thread for each executing user. Which also begs another question: > Even setting NIO aside, how does Shiro find the right subject in the course > of a long user interaction with a web application? E.g. user logins on view > A.xhtml and then clicks on view B.xhtml and continues navigating inside the > application. Is there any guarantee that the web container will use the same > Thread for all subsequent requests ? Otherwise how is Shiro able to > consistently return the same subject in the course of a user's interaction > with the application ? > > As regards to your proposed approach of building the Subjects yourself via > sessionId, I suppose like this: > > Subject subject = (new Subject.Builder()).sessionId(sessionId).buildSubject(); > > From what I understand, the above is only possible when using Shiro native > sessions (not container-managed). > > KR, > Menelaos. > > On Mon, Nov 26, 2012 at 10:11 PM, David Idol <[email protected] > (mailto:[email protected])> wrote: > > I would like to use Shiro with an asynchronous, NIO-based server (JBoss > > Netty). Because this server is based on NIO, it does not use the single > > thread per request model (one selecting thread can be used to service > > multiple requests, or "Channels" in Netty terms). As such, we cannot assume > > that any thread is servicing only a single client. > > > > I would like to associate a Shiro "Subject" with each Netty "Channel"; does > > anyone have any advice on how to do this successfully? The best thing I > > have been able to come up with (although I have not tested it) is building > > Subject instances manually whenever a new Channel is initiated and then > > looking up the Subject in whatever thread is executing via the sessionId > > (which gets sent initially to the client and then received by the server > > with every request). > > > > The application is not a web application (uses persistent socket > > connections instead of HTTP) if that matters. > > > > Thanks, > > David > > > > > > >
