2007-02-16 (금), 08:32 -0600, Greg Duffy 쓰시길: > On 2/16/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > And... closing selectors on unbind sounds reasonable to me. Where the > > problem resides is connector-side. SocketConnector shouldn't close its > > selector just because there's no pending connection attempt. Anyone can > > request connection attempt at any time and creating a selector takes a lot > > of time. Moreover, creating a selector every time a worker thread is > > created made the code more complex than maintaining it as a final member > > field. > Agreed, but could we fix this along with DIRMINA-316?
Sure. > > But... you came up with a great solution; the selector pool! How couldn't I > > think that nice solution? We could probably utilize Jakarta Commons Pool > > here. What do you think? What would be a potential problem if we use the > > selector pool? > A selector pool might be a good solution. But, there's some questions we > have to ask first. > > 1) Should we make it pluggable, as mentioned by Rob below? I think so. > Sometimes, somebody may even just want to open and close immediately. Yes, we need to make it pluggable. I think using commons-pool internally is fine comparing to the cost to create a new selector even if it uses a simple 'synchronized' block. We will have to wrap it up with our own SelectorFactory interface though. > 2) What should be our default implementation? Is Commons Pool still actively > maintained? Is it well tested and performant? (I don't know, just asking > those who might know better) It's well-tested and will perform at least much better than creating a new selector. > 3) Pooling is less deterministic than opening a selector for each > IoConnector/IoAcceptor and closing it in shutdown/unbind. So, can we think > of test cases to keep it running smoothly? Can we give the user better error > messages if the pool can't create more selectors? There will be a few more > variables to tune than normal: pool size and pool death rate vs. the OS file > descriptor limit, etc. The selector pool will fail to create a new selector only when you are out of file descriptor, just like when you don't pool anything at all because it's a matter of 'maximum number.' The only solution to this problem is to increase the maximum number of open files per process per user. Of course, we can log some message using global ExceptionListener to tell the user to increase the 'ulimit -n' value. The pool size should start from 0 without upper limit. We can make it easily configurable because we are going to make the pool implementation pluggable. > 4) Better yet, will anybody actually create/destroy that many > connectors/acceptors every second? Well, maybe. It will at least help MINA beginner bump up to the problem too soon. :) > Anyway, just my thoughts so far. Thanks for the enthusiastic response! > > It sounds like you're going on holiday, and I'm in a real time-crunch on my > current project, so maybe we can revisit this in a week or two. Have a great > holiday, and get some rest! I hope you had a great rest, too! Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
signature.asc
Description: This is a digitally signed message part
