Since changing everything over to MINA could be quite a bit of work, and the issue we have is somewhat serious, we should come up with a short term solution first and release a patch. Perhaps this patch would do the following:
Option 1: Have Max Threads as a configurable option at the server level. Each listener would share the same thread pool. Option 2: Have Max Threads as a configurable option at the listener (acceptor) level. I prefer option 1 as most people would look at the server level rather than listener level. In other words, my server should be able to handle 200 concurrent users. If Max Threads is not specified, may be we should default it to maxUsers/connections that we have. Not sure what the current keep-alive time for the threads is, but perhaps having a shorter keep-alive time may help in some cases, or make it as a configurable option. What do you think? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 8:33 AM, Niklas Gustavsson <nik...@protocol7.com> wrote: > On Tue, Mar 30, 2010 at 2:22 PM, David Latorre <dvl...@gmail.com> wrote: >> I would rather go for a solution that make it impossible to block >> FTPServer rather than making it 'more difficult'. >> For this, we might limit the total number of data connections which >> wouldn't be perfect but might help... or maybe we can enforce a rule >> that MaxUsers < MaxThreads. > > Depending on your user profiles, I think there might be different > configurations that suites you best. So, I think we should supply both > the max concurrent users option (that we do today) and a max threads > option. Then, we need to provide reasonable defaults and documentation > on how to best use them. > >> - We could have a filter that limited bandwidth usage, although I >> don't think there is anything like that in FTPServer. > > We already do bandwidth limitation in our blocking data connections. > > /niklas >
