db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject Re: How should one handle a test case that when it fails will cause a deadlock in Derby Netwok Server
Date Sun, 26 Jun 2016 19:36:43 GMT
I figured to write a test to show the failure which is the case with the current release of
Derby and then once I have the fix, then the test will pass.

I attached a patch with the changes for the test for the issue along with the supporting DerbyWatchdog.java
that detects the Java level deadlock and will allow the test to terminate and not hang.  I
don’t think that this patch should be applied yet, but it can be reviewed and tried to verify
that it is showing the issue.

The test uses the currently lock wait timeout which is 5 seconds and uses a XA transaction
timeout which is 2 seconds.  The watchdog time is set to 30 seconds to look for the Java level
deadlock that occurs.

I am working on a fix for the issue which is going to involve more changes as my simple solution
could cause other deadlocks.  I will update the comment on what I think will be the solution.

> On Jun 24, 2016, at 8:18 PM, Bryan Pendleton <bpendleton.derby@gmail.com> wrote:
>> my test that I added to XATest.java causes the deadlock and the watchdog detects
the deadlock and then does a System.exit(1) to kill the test for now.
> Brett, I think that's a wonderful approach!
> Frankly, I think it is probably more than is strictly-speaking necessary;
> as I understand your proposed fix, the deadlock would only arise in the
> test if your fix were to suffer a regression, right?
> That is, assuming the bug stays fixed, the tests would not deadlock.
> And, if the bug re-occurs, the test would deadlock, but even if it were
> to hang at that point, the developer running the tests would then
> notice that the tests had hung, and would investigate, and so forth.
> But it's even nicer that you have done this extra work to detect that
> and kill the test.
> I suppose the only trick will be, what to set the timeout at?
> I know that machines can vary WIDELY in their performance of the Derby test
> suites, so choosing a timeout that is long enough to not cause false
> positives (claiming there was a deadlock when in fact the test was merely
> running slowly), but still short enough to terminate the tests in a
> responsive fashion might be a bit tricky.
> Anyway, not sure any of this helps, but wanted to give you some feedback
> on the messages you sent.
> thanks,
> bryan

Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300

This e-mail and any attached document(s) is confidential and is intended only for the review
of the party to whom it is addressed. If you have received this transmission in error, please
notify the sender immediately and discard the original message and any attachment(s).

View raw message