Hi David, You may want to extend the netty Channelgroups class. For channels related to the same Subject, you can group them in your own CHannelGroup. This will give you better control when you want to logout(). You can send a future to all channels.You can create a static HashMap<SubjectProperty, YourChannelGroup> to maintain your channelgroups.
2012/11/27 David Idol <[email protected]> > I saw this response by Les, but it seems to focus on using one Subject > for multiple threads. Netty has a thread-pool based implementation, but I'd > like the performance gains of having the asynchronous NIO-based socket > reads, considering I may have many, many clients connected at once. I was > hoping someone out there would have encountered this kind of thing before > and I could learn from their knowledge. > > On Monday, November 26, 2012 at 4:45 PM, Cemo wrote: > > I am also interested in this topic. This is not exact answer of your > question but seems that there is not any work for non single thread models. > You can check details from here: > > > http://mail-archives.apache.org/mod_mbox/shiro-user/201211.mbox/%3ccaatvd4wla_gu_1qofjbloo7ubyolmssa2yrxch-5tq-yzut...@mail.gmail.com%3E > > > > > On 26 November 2012 22:11, David Idol <[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 > > > >
