[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3493:
--------------------------------------
Attachment: d3493-1b.diff
Attaching a new patch (1b) since I mistakenly changed find() and create() so
that they left dummy objects in the cache if Cacheable.setIdentity() or
Cacheable.createIdentity() failed, which led to failures in some of the
recovery tests.
suites.All and derbyall ran cleanly with 1b (except the replication tests, see
DERBY-3517).
On a machine where I saw the hang in stress.multi in about 25% of the runs, I
ran 150 times without seeing the hang with the 1a patch, and 60 times with the
1b patch, so I believe the problem is solved.
> 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: d3493-1a.diff, d3493-1b.diff,
> 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.
