[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575706#action_12575706
]
Knut Anders Hatlen commented on DERBY-3493:
-------------------------------------------
Here's the culprit:
"Thread-10" prio=3 tid=0x085d6c00 nid=0x19 waiting on condition
[0xb6315000..0xb6315be0]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xbb4e6168> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1861)
at
org.apache.derby.impl.services.cache.CacheEntry.lockWhenIdentityIsSet(CacheEntry.java:128)
at
org.apache.derby.impl.services.cache.ConcurrentCache.getEntry(ConcurrentCache.java:122)
at
org.apache.derby.impl.services.cache.ConcurrentCache.findOrCreateObject(ConcurrentCache.java:213)
at
org.apache.derby.impl.services.cache.ConcurrentCache.create(ConcurrentCache.java:343)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addTableDescriptorToOtherCache(DataDictionaryImpl.java:8726)
at
org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:117)
at
org.apache.derby.impl.services.cache.ConcurrentCache.findOrCreateObject(ConcurrentCache.java:254)
at
org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:288)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:1850)
at
org.apache.derby.impl.sql.compile.QueryTreeNode.getTableDescriptor(QueryTreeNode.java:1228)
.
.
.
What happens, is that NameTDCacheable.setIdentity() re-enters the table
descriptor cache and runs into a deadlock. I'll see if I can find a way to fix
it.
> stress.multi times out waiting on testers with blocked testers waiting on the
> same statement
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-3493
> URL: https://issues.apache.org/jira/browse/DERBY-3493
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, SQL, Test
> Affects Versions: 10.4.0.0
> Environment: IBM 1.5 Linux
> Reporter: Kathey Marsden
> Attachments: threaddump-1204806990660.tdump
>
>
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> > skipping last scripts (if any). NOTE: the
> > likely cause of the problem killing testers is
> > probably not enough VM memory OR test cases that
> > run for very long periods of time (so testers do not
> > have a chance to notice stop() requests
> Test Failed.
> The testers that are stuck are stuck on the same statement e.g.
> --
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> The interupt exception shows:
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:199)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn
> ctionContext.java:768)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> The code at line 195 of GenericStatement shows:
> ....
> try {
> preparedStmt.wait();
> } catch (InterruptedException ie) {
> throw StandardException.interrupt(ie);
> }
> My first guess is that this is perhaps some type of Statement cache
> concurrency bug, but perhaps
> I am reading it wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
