db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
Date Sat, 08 Mar 2008 22:59:53 GMT

     [ 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.


Mime
View raw message