db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java
Date Wed, 18 Apr 2012 01:49:13 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256135#comment-13256135
] 

Myrna van Lunteren commented on DERBY-5692:
-------------------------------------------

Thanks for your input, Mike,

Yes, the machine is *very* busy while running the derbyall for 1.4.2, although likely not
more heavily than while running derbyall for the other jvms...
I forgot that this test needs to be run as part of the storetests suite, so only managed to
run it 25 times by now, but if timeout is to be expected *only* during heavy load, then I
don't think running 100 times will pop it either.

The default for the storetests (as per ...tests/storetests/default_derby.properties) is currently:
     derby.locks.deadlockTimeout=1
     derby.locks.waitTimeout=3

I was contemplating disabling the run of this test for ibm 1.4.2 (by adding an st_derby715_app.properties
file with content: runwithibm14=false).

But if this is expected behavior on a busy machine, I can instead add a st_derby715_derby.properties
that sets:
     derby.locks.deadlockTimeout=1
     derby.locks.waitTimeout=60
Is that what you meant?
   
                
> intermittent test failure in storetests/st_derby715.java
> --------------------------------------------------------
>
>                 Key: DERBY-5692
>                 URL: https://issues.apache.org/jira/browse/DERBY-5692
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.8.2.3
>         Environment: Windows 2008, 4 CPU, ibm 1.4.2.
>            Reporter: Myrna van Lunteren
>            Priority: Minor
>
> I am seeing an irregularly occurring failure with ibm 1.4.2 on one machine - which happens
to be the only 4 CPU machine and the only one running Windows 2008...And I've got 10.8 nightly
tests running on it.
> I have not seen this with other jvms on the same machine.
> It's possible this would also happen on trunk, but we stopped supporting 1.4.2 with trunk
and so I do not run tests against trunk with (ibm) 1.4.2.
> When the test passes, the output contains 5 identical lines 'Got a Deadlock'.
> The test failures are of 2 kinds:
> - 1 (or more?) of the 'Got a Deadlock' lines is missing
> - we get a '40XL1' error (timeout) instead of a deadlock.
> As the second situation seems to match what DERBY-715 was about, I thought it worthwhile
reporting as a separate JIRA. We should check it's not somehow a regression.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message