Trustin, Please make the pool implementation pluggable. Apache commons pool is pretty basic and limited in functionality. Of course I never have time, but at some point I hope to implement (or find) a much better pool implementation.
Rob ----- Original Message ---- From: Trustin Lee <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 16, 2007 7:48:30 AM Subject: Re: Datagram implementation question 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 ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
