[
https://issues.apache.org/jira/browse/DERBY-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4711:
--------------------------------------
Attachment: junit-timing-fix.diff
A problem with the new test was reported on derby-dev:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/201006.mbox/%[email protected]%3e
The problem appears to be that the commit in the main thread may allow the
waiting thread to continue before it has received the interrupt, and thus it
doesn't fail as it is supposed to. Adding a sleep between t1.interrupt() and
commit() gives the interrupt time to propagate to the waiter before the main
thread commits and releases its locks. See the attached patch
junit-timing-fix.diff.
The test failed on almost every run in my environment when using insane jars.
After patching the test, I've run it 200 times without seeing the failure.
> Hung thread after another thread is interrupted
> -----------------------------------------------
>
> Key: DERBY-4711
> URL: https://issues.apache.org/jira/browse/DERBY-4711
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.5.3.0
> Environment: Windows server 2008
> Reporter: Luke Quinane
> Assignee: Luke Quinane
> Fix For: 10.7.0.0
>
> Attachments: interrupted-exception-fix.diff,
> interrupted-exception-fix.patch, junit-timing-fix.diff, junit.diff
>
>
> We've seen a problem today where we have several threads querying our
> database and when one gets interrupted the others are stuck waiting for a
> lock. Here is the stack trace for the stuck thread(s):
> daemon prio=4
> "DefaultExecutorService-pool-1-thread-47" Id=98 WAITING on
> org.apache.derby.impl.services.locks.activel...@6e6f45a1
> at java.lang.Object.wait(Native Method)
> - waiting on org.apache.derby.impl.services.locks.activel...@6e6f45a1
> at java.lang.Object.wait(Object.java:485)
> at
> org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:115)
> at
> org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:463)
> at
> org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(ConcurrentLockSet.java:855)
> at
> org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(AbstractPool.java:297)
> at
> org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(ConcurrentPool.java:28)
> at
> org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(RowLocking2nohold.java:89)
> at
> org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:520)
> at
> org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638)
> at
> org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:309)
> at
> org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599)
> at
> org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105)
> at
> org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:305)
> at
> org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1585)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:327)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:282)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:460)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:427)
> - locked org.apache.derby.impl.jdbc.embedconnectio...@445d374b
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:371)
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
