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? -Greg On 2/3/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
Hi Greg, On 2/3/07, Greg Duffy <[EMAIL PROTECTED]> wrote: > > Hi MINA crew! > > I have a couple of questions about the current datagram transport > implementation. I'm using the svn trunk directly (2.0.0-M1-SNAPSHOT). > > Is there a reason that DatagramAcceptor and DatagramConnector use a > delegate > pattern? Also, is there a reason that they can't have multiple processor > threads like their socket counterparts? I used delegate pattern to hide DatagramService (in datagam.supportpackage) interface which provides public internal methods (e.g. flushSession). It would be better if there's a way that doesn't use a delegate pattern. As you know, datagram transport doesn't have more popularity than socket transport. That's why we didn't implement multiple processor threads yet. We've been focusing on socket transport. There's no other reason, and datagram transport needs improvement definitely. I don't know if there is an architectural difficulty I'm missing, or if > there hasn't been enough dev time/interest to spruce up the datagram > implementation, or maybe something completely different. If it's just the > lack of dev interest or time, I might be able to make a patch for it. I've > done one other MINA patch for the IoSessionRecycler, so I've at least > gotten > my feet a little wet in terms of contributing. (and I even know now not to > accidentally hit my Eclipse format shortcut before submitting my patch!) Your patch is always welcome! It is always great to have someone who deals with various transport types. Julien is working on serial / parallel port support, and you could lend us your hands to improve our datagram support. :) What do you think? Are there any gotchas that I don't see? You didn't misunderstand anything. I am impressed! Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
