Hi Peter, Thanks for your answer. If I implemented logging in the filterchain, doesn't that have a chance of blocking IO on the server until it completes, because the filters are running in the IoProcessor thread? It has to fetch a user record from the DB and generate a secret, and do some MD5ing before it would be removed. I don't think that takes too long, but maybe on days when the database was getting hit hard. That's why I am thinking that the authentication should go in the Session Handler instead, which is already sitting behing a pile of threads, and authentication speed won't affect the performance of the IoProcessors.
Speaking of the threading, I am using the CachedThreadPool for my protcol handler. This is an unbounded pool, so If my server gets really busy, it could end up creating a lot of threads, right? Granted they would be hopefully short lived threads but doesn't this sometimes cause a performance hit? I know the other option would be to use a bounded but expandable ThreadPoolExecutor, which would have the drawback that once max threads are hit, some clients will have to wait, but if everything is tuned right the active requests should finish soon... Because if we had 1000 connections sending messages to the server simultaneously, it seems that the cached threadpool could end up spawning that number of threads to deal with it, and we may get into cpu thrashing in the context switcher. Or am I wrong, and in practice the life of a message is short enough that you don't end up with so many threads...? I would be interested to know if in Trustin's load testing with AsyncWeb vs Apache if the IOHandler was using a CachedThreadPool or not, and what was the max number of threads spwaned at any time if it was. Thanks! --brigham # -----Original Message----- # From: peter royal [mailto:[EMAIL PROTECTED] # Sent: Monday, April 23, 2007 3:30 PM # To: [email protected] # Subject: Re: Authentication filter # # On Apr 23, 2007, at 10:51 AM, Brigham Stevens wrote: # > Authentication in my app will require a database lookup, # and once the # > IoSession is authorized, I won't need to do that anymore. So to # > implement this as a filter, would I insert an ExecutorFilter before # > the Authentication filter to make sure the database work is # offloaded # > to another thread? What about future messages after authentication, # > they will still be routed through these filters, and through the # > thread too, it seems like it would add latency. I already have an # > executor filter in place to take care of my IOHandler. # # If you already have an ExecutorFilter, don't add another one. # # You could use the fact that a filter chain is per-session and # dynamic. After a session is authenticated, your auth filter # could remove itself from the chain. Or just set a flag and # have it pass- through. # # > Also, just out of curiosity, for my main IOHandler if I were to use # > ChainedIoHandlers instead of IoHandlers, would I add an # ExecutorFilter # > before each one to give each their own thread pool? # # Generally a single ExecutorFilter is enough. I'd start with # that for now :) # # > thanks in advance. I'm new to MINA and this list. # # welcome! # # -pete # # # -- # [EMAIL PROTECTED] - http://fotap.org/~osi # # # #
