Bug184060

Collect thread name when reaping a pooled connection

Severity

4

Affected versions

5.0.x

Description

You can now more easily determine when connections are reaped because of another connection timing out on network I/O or DB locks.

Technical details

We already used to collect the stack trace of the thread that acquired a reaped connection. However, we now also collect the thread name to correlate reap situations with timeouts, for instance like this:

1. a JMS connection is gotten
2. attempt to get a JDBC connection / times out while blocking on the testQuery
3. reaping of the JMS connection in 1 by the pool's maintenance thread

Before this fix, you would see a timeout + application's thread name + stack trace for step 2, and a stack trace for 3. The stack trace would show where in your application the connection was gotten in step 1, but not by which thread. Indeed, step 3 would log the stack trace within the context of the pool maintenance thread, not the original application thread in step 1.

With this fix you will now also see the application's thread name (i.e., the thread of step 2) in step 3 so you can easily correlate 1-2-3 and determine the timeout in 2 as the root cause for the reap.

Changes impacting client API

None.

Release notes for 5.0.99

Release notes for 4.0.81

Release notes for 5.0.98