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] Commented: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
Date Thu, 06 Mar 2008 14:02:59 GMT

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


Mime
View raw message