2010/3/30 Niklas Gustavsson <nik...@protocol7.com>: > On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla > <sai.pullabho...@jmethods.com> wrote: >> I don't think that was intended. If this is in fact an issue, we >> should probably consider adding a configuration option such as >> maxThreads as the default max we choose may not be the best in all >> cases. > > I think David is correct, and I agree with your proposed solution > (defaulting the value higher than 16 thou). We should also look into > moving the data connection over to using MINA, if someone got the > time.
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. Regarding the move of the data connection to MINA, I understand Sai's position that is using blocking-IO here is probably lighter ( It would be nice if we could have the same 'MINA pipeline' accepting on several ports...). Still I see an advantage if we used MINA - filters: - We could have different filters for ASCII mode, binary mode, 'Z' mode or other modes of encoding we or the users might think of (Although it is easy to have custom streams that do this for us with the current implementation). - We can include a fine grained monitoring of current transfers, a filter might inform via JMX or other means of e.g., the amount of data transferred - A filter could limit the quota for a user, for a session, for a week/month for this user in 'real time'. There are other ways to do this as well... - We could have a filter that limited bandwidth usage, although I don't think there is anything like that in FTPServer. Still, several of the possibilities we can think of seem not that useful since we should have multiple 'chains' for data connections. > /niklas >
