Commons pool itself may be OK. It is the underlying pool implementation used by Apache DB Connection Pool (DBCP). I've had problems with DBCP in the past. Specifically I used the connection testing feature to verify connections were still "live". I had this run every 30 minutes or so. There is some bug in DBCP because it closed all my connections every 30 minutes and re-established the minimum number of connections. This caused unnecessary overhead on my DB.
Commons pool doesn't have a lot of features either, it is a fairly simple pooling implementation. To the best of my knowledge, there is no JMX support for monitoring the pool. No way to safely increase/decrease the pool at runtime and no way to gather pool usage statistics. For the core functionality of a pool these things aren't needed, but they are really nice to have. I don't recall the pool having a lot of lifecycle callbacks either. You may want to do something to your pooled objects before/after they are borrowed/returned, or after they have been idle for some time. Also commons pool is rather old. With the new concurrency utilities in Java 5 it might be possible to implement a more performant pool. There are numerous pooling strategies/algorithms as well. Commons pool only implements a few (although it does provide an interface to implement your own). There could be a vast array of different pooling strategies people would want to use. Probably more than we could ever think of. So it would be good to provide a way that people can plug in what they need. Rob ----- Original Message ---- From: Greg Duffy <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 16, 2007 9:35:46 AM Subject: Re: Datagram implementation question 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 > ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
