This re­lease will be su­per­seded by the up­com­ing re­lease 5.0.102. Please ig­nore this one.

Bug184060

Col­lect thread name when reap­ing a pooled con­nec­tion

Sever­i­ty

4

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

You can now more eas­i­ly de­ter­mine when con­nec­tions are reaped be­cause of an­oth­er con­nec­tion tim­ing out on net­work I/O or DB locks.

Tech­ni­cal de­tails

We al­ready used to col­lect the stack trace of the thread that ac­quired a reaped con­nec­tion. How­ev­er, we now also col­lect the thread name to cor­re­late reap sit­u­a­tions with time­outs, for in­stance like this:

1. a JMS con­nec­tion is got­ten
2. at­tempt to get a JDBC con­nec­tion / times out while block­ing on the testQuery
3. reap­ing of the JMS con­nec­tion in 1 by the pool's main­te­nance thread

Be­fore this fix, you would see a time­out + ap­pli­ca­tion's thread name + stack trace for step 2, and a stack trace for 3. The stack trace would show where in your ap­pli­ca­tion the con­nec­tion was got­ten in step 1, but not by which thread. In­deed, step 3 would log the stack trace with­in the con­text of the pool main­te­nance thread, not the orig­i­nal ap­pli­ca­tion thread in step 1.

With this fix you will now also see the ap­pli­ca­tion's thread name (i.e., the thread of step 2) in step 3 so you can eas­i­ly cor­re­late 1-2-3 and de­ter­mine the time­out in 2 as the root cause for the reap.

Changes im­pact­ing client API

None.

Re­lease notes for 5.0.99

In this ar­ti­cle we'll be de­bunk­ing 4 mi­croser­vice myths that can get you into trou­ble, and point you to­wards 5 com­mon pit­falls that will ruin your data con­sis­ten­cy in the long run...

Re­lease notes for 4.0.81