[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575711#action_12575711
]
Knut Anders Hatlen commented on DERBY-3493:
-------------------------------------------
Clock.create() seems to fail earlier than ConcurrentCache.create() when it
discovers that the object already exists in the cache. Clock.create() will fail
as soon as it sees that there is an entry with the same identity.
ConcurrentCache.create() will wait until the entry has been successfully
initialized before it fails. I think the hang will go away if
ConcurrentCache.create() also fails earlier.
> 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
> Assignee: Knut Anders Hatlen
> 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.
