[
https://issues.apache.org/jira/browse/DERBY-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986207#action_12986207
]
Dag H. Wanvik edited comment on DERBY-4982 at 1/24/11 11:07 PM:
----------------------------------------------------------------
This error is due to the way the method T_Unit#checkGetLatchedPage works. This
method calls into the internal Derby Page classes to test latching of pages.
The structure of this test code mirrors how the code in BasePage#setExclusive
works in the following scenario:
The Derby store code is wrong internally somehow, so an attempt is made to grab
the same latch twice. This condition is tested for by checkGetLatchedPage and
it treats it differently in sane and insane mode as does store.
BasePage#setExclusive does the following:
- in sane mode, an assert error is thrown
- in insane mode, the code will do a wait on the monitor and rely on lock
time-out to break the stalemate (waiting for itself...)
Now, the test T_RawStoreFactory#P024 calls T_Unit#checkGetLatchedPage. The
latter "knows" that in insane mode, a hang can be expected when it tries
to acquire a lack for the second time, so to get out of this, it fires off a
thread which will shoot down the hanging user thread with an interrupt, so as
to get control back: 08000 is expected.
With the changes in DERBY-4741, interrupting the test thread no longer works,
since the wait in setExclusive just retries. This means that in insane mode,
the tests hangs until the harness' time bomb goes off. I ran my regression
tests in sane mode, which wasn't affected by this logic, and was thus
blind-sided.
was (Author: dagw):
This error is due to the way the method T_Unit#checkGetLatchedPage works.
This method calls into the internal Derby Page classes to test latching of
pages. The structure of this test code mirrors how the code in
BasePage#setExclusive works in the following scenario:
The Derby store code is wrong internally somehow, so an attempt is made to grab
the same latch twice. This condition is tested for by checkGetLatchedPage and
it treats it differently in sane and insane mode.
- in sane mode, an assert error is thrown
- in insane mode, the code will do a wait on the monitor and rely on lock
time-out to break the stalemate (waiting for itself...)
Now, the test T_RawStoreFactory#P024 calls T_Unit#checkGetLatchedPage. The
latter "knows" that in insane mode, a hang can be expected when it tries
to acquire a lack for the second time, so to get out of this, it fires off a
thread which will shoot down the hanging user thread with an interrupt, so as
to get control back: 08000 is expected.
With the changes in DERBY-4741, interrupting the test thread no longer works,
since the wait in setExclusive just retries. This means that in insane mode,
the tests hangs until the harness' time bomb goes off. I ran my regression
tests in sane mode, which wasn't affected by this logic, and was thus
blind-sided.
> Retrying after interrupts in store pops a bug in
> derbyall/storeall/storeunit/T_RawStoreFactory in some cases
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4982
> URL: https://issues.apache.org/jira/browse/DERBY-4982
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.8.0.0
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
>
> Cf Myrna's comment on DERBY-4741:
> "I think the latest check-in has caused the following tinderbox failure:
> derbyall/storeall/storeall.fail:unit/T_RawStoreFactory.unit
> see:
> http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/1061516-derbyall_diff.txt:
> ********* Diff file derbyall/storeall/storeunit/T_RawStoreFactory.diff
> *** Start: T_RawStoreFactory jdk1.6.0_18 storeall:storeunit 2011-01-20
> 23:22:23 ***
> 2 del
> < -- Unit Test T_RawStoreFactory finished
> 2 add
> > ran out of time
> > Exit due to time bomb
> Test Failed.
> *** End: T_RawStoreFactory jdk1.6.0_18 storeall:storeunit 2011-01-21 00:22:54
> ***
> "
> It failed in the nightly runs with ibm 1.6 also (and 1.4.2 and 1.5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
