On 01/12/2010 02:06 AM, Gary Tully wrote: > Hi Marshall, > can you add your configuration to that jira. I wonder/could a jdbc pool > timeout or periodic check help to ensure that expired connections are reaped > by the pool before being returned to the jdbc persistence adapter? > > Do you find that the symptom is unrecoverable, that is, you see the stack > traces repeated and only a restart will clear it? > > > 2010/1/12 Marshall Pierce <marsh...@genius.com> > >> I filed a Jira case about this a while ago, but nothing's happened on >> it. https://issues.apache.org/activemq/browse/AMQ-2534 >> >> This happened most often on less-active environments which leads me to >> think it's related to some inactivity timeout or something. Let me know >> if I can help diagnose it. >> > > >
I've updated the Jira with the config. Once the issue has happened, no messages flow at all. I'm not sure if it will refuse to accept more messages or if the problem is restricted to not being able to dequeue messages, but either way, I haven't found a way to fix it without restarting. It's possible that a periodic check would help, but if connections were timing out, that would be a different exception. Mysql will complain if you use an expired connection by saying something along the lines of "It's been 561264 seconds since the last packet". In another project I'm using C3P0 for jdbc pooling and I've configured periodic testing like so: c3p0.preferredTestQuery = (trivial query) That and autoReconnect=true in the jdbc url solved my connection timeout issues, but that problem had a different root exception that clearly identified the problem as a connection timeout.
