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 "Kathey Marsden (JIRA)" <ji...@apache.org> on 2011/03/15 23:26:29 UTC

[jira] Created: (DERBY-5137) Enable or remove Derby3980DeadlockTest

Enable or remove Derby3980DeadlockTest
--------------------------------------

                 Key: DERBY-5137
                 URL: https://issues.apache.org/jira/browse/DERBY-5137
             Project: Derby
          Issue Type: Improvement
    Affects Versions: 10.8.0.0
            Reporter: Kathey Marsden


As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   

I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
This this test should be enabled or removed if it adds no additional coverage. 

Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");

One thing to note is that it now, with the IBM JVM, I  think correctly will print 
JVMDUMP010I Java dump written to ...

I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest

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

Kathey Marsden commented on DERBY-5137:
---------------------------------------

I think the testing in T_RawStoreFactory etc, is to use extendedDiagSeverity to suppress the thread dump for certain errors so I think it is good to have a test for when it is used to generate the thread dump for diagnostics and a Deadlock case would be best as I think that is how it will normally be used.  

I think moving the extendedDiagSeverity test to DeadlockDetectionTest would be fine and don't see any rush to do this. Thank you again for buddy testing and all you do for Derby.



> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.8.0.0
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest

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

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

Sorry, I didn't notice that there already was a test for the issue when I checked in the fix for DERBY-3980.

Apart from the security manager magic, the test case looks more or less identical to the one checked in together with the fix, and enabling it wouldn't add any coverage. I don't understand what's achieved by using a custom security policy in that test. If it's meant for testing extendedDiagSeverity and/or security managers, it would probably be better to move that part into a test dedicated to that purpose, and also adding some comments explaining what's being tested.

If we enable the test, we should probably add some more synchronization between the two threads. Currently, the test doesn't ensure that both threads have performed the select query before they perform the delete. I think this means that it's possible that one of the threads has performed both the select and the delete before the other thread has done the select, and then we may see intermittent test failures because there is no deadlock. But since the test scenario is so similar to the one in DeadlockDetectionTest, it's probably fine just to remove this test.

> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.8.0.0
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest

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

Kathey Marsden commented on DERBY-5137:
---------------------------------------

I think the special policy file is for the extendedDiagSeverity testing, so that it can generate thread dumps, but might be wrong. I think it makes sense to move the extendedDiagSeverityTesting elsewhere and remove this test to avoid confusion.



> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.8.0.0
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5137) Enable or remove Derby3980DeadlockTest

Posted by "Kathey Marsden (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-5137:
----------------------------------

    Component/s: Test
    
> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions: 10.8.1.2
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
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-5137) Enable or remove Derby3980DeadlockTest

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

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

I would prefer not to move the extendedDiagSeverity test to DeadlockDetectionTest. DeadlockDetectionTest is meant to test one specific part of the code: the deadlock detection algorithm. Adding testing of different aspects of the code into that test is confusing, in my opinion.

> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.8.0.0
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest

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

Lily Wei commented on DERBY-5137:
---------------------------------

extendedDiagSeverity test exists for T_RawStoreFactory etc. The special policy file is added to allow creating javadoc* file for ibm jvm. When doing the test, I did encounter issue in turn of thread dump information did not show up in derby.log. However, due to need more synchronization between the two threads, it might not be the most ideal case to add extenedDiagSeverity to Derby3980DeadlockTest. it is fine with me to remove this test. Is it okay to add the extenedDiagSeverity to DeadlockDetectionTest? I am still working on buddy testing JDBC 4.1. If it is okay to add generating javadoc* file testing for extendedDiagSeverity to DeadlockDectioinTest. If it is okay, I will add it after finish buddy testing. Thanks!

> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
>                 Key: DERBY-5137
>                 URL: https://issues.apache.org/jira/browse/DERBY-5137
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.8.0.0
>            Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in  an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest.   
> I verified it does pass now but maybe the new DeadLockDetectionTest  provides the same coverage.
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level and 
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel", "30000");
> One thing to note is that it now, with the IBM JVM, I  think correctly will print 
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira