Thanks, Jeremy. I will work on that. Should I extend the ThreadedConnectionPool or create a brand new implementation?
On Aug 16, 10:14 am, Jeremy Evans <[email protected]> wrote: > On Aug 16, 6:12 am, Jason Rogers <[email protected]> wrote: > > > I am running an application in a Tomcat 7 container. I initially set > > my pool for 20 connections to do some load testing. My load tests > > don't run constantly, we start them up, let them go for a few hours, > > then shut them down. For the first day or so the tests run fine. After > > that I start getting stale connections from the pool (e.g. > > Communications link failure\nThe last packet sent successfully to the > > server was 51876345 milliseconds ago. The driver has not received any > > packets from the server.). The last packet in this example was sent to > > the server 14.41 hours previously, and the server has closed the > > connection. > > > I know this isn't a problem with Sequel. My question is: how can I > > hook into the pool to proactively sweep these bad connections? Do I > > need to write my own reaper thread that will do a simple select (like > > "SELECT 1") every so often to make sure the connections are valid? > > Currently, you probably want to write your own reaper thread. > > > What I would really like to do is to be able to send more options to > > the pool. It would be great if we could specify the options from the > > Apache Commons DBCP > > project:http://commons.apache.org/dbcp/configuration.html > > . The options I think that are particularly applicable there are > > initialSize, maxActive, maxIdle, minIdle, testWhileIdle, and the > > eviction parameters. These are finer grained options that would allow > > the user to tune the pool a little easier. > > They'd also add complexity that wouldn't benefit many users, and > checking all the settings isn't free in terms of performance. I'd > consider a new connection pool class that subclassed the existing one > and added support for them. If you send in a patch with specs I'll > certainly consider it. > > Thanks, > Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
