Hi Greg, On 2/16/07, Greg Duffy <[EMAIL PROTECTED]> wrote:
Hi, I'm in the process of completely recoding DatagramAcceptor and DatagramConnector for MINA (will be done in a week or two, as I'm busy with other stuff), and I just noticed this old issue: http://issues.apache.org/jira/browse/DIRMINA-154 As Trustin mentioned in the comments of that issue, Sun fixed a file descriptor leak in DatagramSocket/DatagramChannel. However, there is another unrelated file descriptor leak in DatagramAcceptor. It's the selector. It seems that MINA is closing selectors in the IoAcceptors' finalizers. These finalizers may not get called before the process runs out of file descriptors, especially for short-lived IoAcceptors. The heap is big, but file descriptor limits are usually small (approx. 1000-10000 per process by default, depending on OS). In my app, which binds and unbinds to many ephemeral ports for each transaction, I run out of file descriptors in about 5 minutes under load. When closing the selector immediately, it hasn't run out for over 24 hours. So, I think we should close selectors immediately after unbinding (cancellation) and/or maybe even pool selectors. So, maybe we could implement the immediate closure as a bug fix now and do some performance testing to decide on selector pooling. I can open and close about 1100 selectors per second on my machine. Is it worth it? I think this issue affects SocketAcceptor too. What do you think?
First, WOW! I really want to see what your datagram implementation looks like. I bet it's much better than what I 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. 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? Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
