Rob, Could you elaborate on this a bit? I definitely agree that any selector pool implementation should be pluggable, especially because some people might not want pooling at all. I'd just like to know what functionality you want that is missing in Commons Pool so I can better evaluate our options. It's been a while since I've used Commons Pool, but I do remember finding some limitations.
Does anybody else have recent experience with it? -Greg On 2/16/07, Rob Butler <[EMAIL PROTECTED]> wrote:
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
