On 2/16/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
Hi Greg,
<SNIP>
First, WOW! I really want to see what your datagram implementation looks
like. I bet it's much better than what I wrote. :)
Well, I wouldn't have thought up the awesome architecture that you came up with for MINA. So, if I can help out with the plumbing, it's my pleasure! I understand completely that we focus on the area of the software that we use the most, especially since MINA is open source, so why shouldn't I be the one to improve the datagram stuff that I use a lot? :) 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? 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. 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) 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. 4) Better yet, will anybody actually create/destroy that many connectors/acceptors every second? Well, maybe. Thanks,
Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
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! -Greg
