You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (Created) (JIRA)" <ji...@apache.org> on 2012/04/17 20:17:21 UTC

[jira] [Created] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

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

        

[jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257440#comment-13257440 ] 

Knut Anders Hatlen commented on DERBY-5692:
-------------------------------------------

Don't know if that's why the test behaves differently, but Derby uses a different implementation of the lock manager on 1.4.2 (since java.util.concurrent.* is only available on 1.5 and later).
                
> 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

        

[jira] [Resolved] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Myrna van Lunteren (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren resolved DERBY-5692.
---------------------------------------

       Resolution: Fixed
    Fix Version/s: 10.9.0.0
                   10.8.2.3
         Assignee: Myrna van Lunteren

Thanks Knut for that theory/explanation.
I followed Mike's suggestion and ran storetests with, and without the additional st_derby715_derby.properties file, and did not see any change in performance on my machine; the entire suite took between 1 and 2 minutes, and the st_derby715 test took 11 or 12 minutes, either way. I ran each with both ibm 142 and 1.6, each with and without the new properties file, and each combination 3 times.
(In passing, I noted that the suite seemed to take about 10 seconds longer with ibm 142 than with 1.6).

I committed the change with revision 1328061 on trunk, and backported to 10.8 with revision 1328075.

I'm resolving this issue; but because without a repro this is a bit of a guess, it can be reopened if the test fails again.

                
> 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
>            Assignee: Myrna van Lunteren
>            Priority: Minor
>             Fix For: 10.8.2.3, 10.9.0.0
>
>
> 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

        

[jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433639#comment-13433639 ] 

Mamta A. Satoor commented on DERBY-5692:
----------------------------------------

Saw following failure on trunk run on Windows/VMWare using ibm jdk1.6
*** Start: st_derby715 jdk1.6.0 storeall:storetests 2012-08-13 01:36:24 ***
3 del
< Got a Deadlock.
< Got a Deadlock.
Test Failed.
*** End:   st_derby715 jdk1.6.0 storeall:storetests 2012-08-13 01:37:24 ***

                
> 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
>            Assignee: Myrna van Lunteren
>            Priority: Minor
>             Fix For: 10.8.2.3, 10.9.1.0
>
>
> 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

        

[jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255835#comment-13255835 ] 

Mike Matrigali commented on DERBY-5692:
---------------------------------------

Is it likely the machine is heavily loaded with other stuff running while the derbyall for 1.4.2 is running?  I think that timeout
could be returned in this case.  I would suggest changing the defaults for that test to make deadlock checking something like
1 second and timeout testing something like 1 minute, to make sure machine load does not adversely affect results.  

Can you run that test 100 times alone on the machine and see any failures?
                
> 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

        

[jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Myrna van Lunteren (Commented) (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Commented] (DERBY-5692) intermittent test failure in storetests/st_derby715.java

Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256630#comment-13256630 ] 

Mike Matrigali commented on DERBY-5692:
---------------------------------------

without a reliable repro hard to say what is going on, which is why I suggested running just that test/suite to see if it pops
easily in that environment.   I am just guessing at why it happens on that platform and not others.  I think the way the locking
code works we don't really know why we have woken up when we sleep waiting for a lock.   If we have not gotten the lock then
we check how long we have waited and if it is under timeout we do the dealock check.

Yes I am suggesting the kind of change you have, but would see how much longer if at all the storetests suite takes with
it.  I don't know how many expected lock timeouts, if any the suite has.
                
> 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