Derby
  1. Derby
  2. DERBY-4856

Add thread dump information when derby crash

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.8.1.2
    • Component/s: Services
    • Labels:
      None
    • Issue & fix info:
      High Value Fix, Patch Available, Release Note Needed

      Description

      On system crash or session ending error, Derby should dump as much information as possible. Such as: forcing a javacore if possible or at least thread dump and system environment information. This should only occur if a running session crashes not on boot error due to fail recovery etc.
      The IBM jvm provides a way to programmatically dump a javacore. i.e. com.ibm.jvm.Dump.JavaDump() And, the SUN jvm will force a thread dump using the Unsafe class and there may be a better way.

      1. releaseNote.html
        5 kB
        Lily Wei
      2. releaseNote.html
        5 kB
        Lily Wei
      3. releaseNote.html
        5 kB
        Lily Wei
      4. releaseNote.html
        5 kB
        Lily Wei
      5. releaseNote.html
        6 kB
        Knut Anders Hatlen
      6. releaseNote.html
        5 kB
        Rick Hillegas
      7. DERBY-4856-part_1_1a.diff
        14 kB
        Lily Wei
      8. derby-4856-1a.diff
        16 kB
        Lily Wei
      9. DERBY-4856_part_3_3g.diff
        56 kB
        Lily Wei
      10. DERBY-4856_part_3_3g_2a.diff
        1 kB
        Lily Wei
      11. DERBY-4856_part_3_3g_1a.diff
        1 kB
        Lily Wei
      12. DERBY-4856_part_3_3e.diff
        56 kB
        Lily Wei
      13. DERBY-4856_part_3_3d.diff
        28 kB
        Lily Wei
      14. DERBY-4856_part_3_3c.diff
        27 kB
        Lily Wei
      15. DERBY-4856_part_3_3b.diff
        23 kB
        Lily Wei
      16. DERBY-4856_part_3_3a.diff
        28 kB
        Lily Wei
      17. DERBY-4856_part_3_2a.diff
        29 kB
        Lily Wei
      18. DERBY-4856_part_3_1a.diff
        8 kB
        Lily Wei
      19. DERBY-4856_part_2_2b.diff
        15 kB
        Lily Wei
      20. DERBY-4856_part_2_2a.diff
        16 kB
        Lily Wei
      21. derby.log
        26 kB
        Lily Wei
      22. corruptdb.zip
        58 kB
        Kathey Marsden
      23. ContextManager.java
        17 kB
        Lily Wei

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          I recently had to do a programatic dump of information on a Sun JVM and found this:
          http://forums.oracle.com/forums/thread.jspa?threadID=1237584&tstart=15

          The file did not have the system properties or shell environment. I printed the system properties as below, but between the two seemed to still be missing a of information, like the shell environment and the command line,

          System.out.println("\n\n------ Java System Properties -----");
          Properties sprops = System.getProperties();
          Set listem;
          String str;

          listem = sprops.keySet();
          Iterator itr = listem.iterator();

          System.out.println("props test");
          while (itr.hasNext())

          { str = (String) itr.next(); System.out.println("key: " + str +"\t;value: " + sprops.getProperty(str)); }

          System.out.println("---- end System Properties output ----\n\n");

          Show
          Kathey Marsden added a comment - I recently had to do a programatic dump of information on a Sun JVM and found this: http://forums.oracle.com/forums/thread.jspa?threadID=1237584&tstart=15 The file did not have the system properties or shell environment. I printed the system properties as below, but between the two seemed to still be missing a of information, like the shell environment and the command line, System.out.println("\n\n------ Java System Properties -----"); Properties sprops = System.getProperties(); Set listem; String str; listem = sprops.keySet(); Iterator itr = listem.iterator(); System.out.println("props test"); while (itr.hasNext()) { str = (String) itr.next(); System.out.println("key: " + str +"\t;value: " + sprops.getProperty(str)); } System.out.println("---- end System Properties output ----\n\n");
          Hide
          Dag H. Wanvik added a comment -

          Thread.getAllStackTraces may be useful? (>= 1.5 though)

          Show
          Dag H. Wanvik added a comment - Thread.getAllStackTraces may be useful? (>= 1.5 though)
          Hide
          Kathey Marsden added a comment -

          I think ultimately the information should dump only for ExceptionSeverity.SESSION_SEVERITY errors or higher if the derby engine is booted, but while developing you may want to leave the boot check out and the use this corrupt database which will fail to connect and produce a ExceptionSeverity.DATABASE_SEVERITY error.

          Lily also mentioned to me two other types of errors that might need to be reported, java exceptions that don't get caught and wrapped in SQLExceptions like some NullPointerExceptions and also it would be nice ultimate to include low cost asserts in insane builds. I am not quite sure how this should be accomplished.

          Show
          Kathey Marsden added a comment - I think ultimately the information should dump only for ExceptionSeverity.SESSION_SEVERITY errors or higher if the derby engine is booted, but while developing you may want to leave the boot check out and the use this corrupt database which will fail to connect and produce a ExceptionSeverity.DATABASE_SEVERITY error. Lily also mentioned to me two other types of errors that might need to be reported, java exceptions that don't get caught and wrapped in SQLExceptions like some NullPointerExceptions and also it would be nice ultimate to include low cost asserts in insane builds. I am not quite sure how this should be accomplished.
          Hide
          Lily Wei added a comment -

          Thanks to Kathey. I am able to construct first attempt to add thread dump on insane build for embedded server.
          I am puzzling on whether the StandardException.printStackTrace(PrintWriter s) for severity >= ExceptionSeverity.SESSION_SEVERITY is the best place to print out thread dump or place like ErrorStringBuilder.stackTrace is better. Personally, I think it shouldn't be that much noise to put in StandardException.printStackTrace(PrinterWriter s) Any opinion is welcome. Please review the code and give me your opinion. Thanks.

          Show
          Lily Wei added a comment - Thanks to Kathey. I am able to construct first attempt to add thread dump on insane build for embedded server. I am puzzling on whether the StandardException.printStackTrace(PrintWriter s) for severity >= ExceptionSeverity.SESSION_SEVERITY is the best place to print out thread dump or place like ErrorStringBuilder.stackTrace is better. Personally, I think it shouldn't be that much noise to put in StandardException.printStackTrace(PrinterWriter s) Any opinion is welcome. Please review the code and give me your opinion. Thanks.
          Hide
          Lily Wei added a comment -

          The changes included:
          1. Move ThreadDump.java from java/shared/org/apache/derby/shared/common/sanity to java/shard/org/apache/derby/shared/common/error
          2. move dumpThreads method from AssertFailure to ExceptionUtil
          3. Add printStackTrace to StandardException when severity >= ExceptionSeverity.SESSION_SEVERITY
          You can find thread dump information in derby.log for corruptdb database

          Hope this is helpful.

          Show
          Lily Wei added a comment - The changes included: 1. Move ThreadDump.java from java/shared/org/apache/derby/shared/common/sanity to java/shard/org/apache/derby/shared/common/error 2. move dumpThreads method from AssertFailure to ExceptionUtil 3. Add printStackTrace to StandardException when severity >= ExceptionSeverity.SESSION_SEVERITY You can find thread dump information in derby.log for corruptdb database Hope this is helpful.
          Hide
          Knut Anders Hatlen added a comment -

          I'd prefer that we don't change the behaviour of StandardException.printStackTrace(), as that may be confusing to the users and may also make the output from the applications noisy and harder to read. To me it sounds sufficient to dump this information to derby.log and not include the thread dump in the exception itself. What about adding the code to ContextManager.cleanupOnError() instead? That's where the writing of errors to derby.log happens.

          Show
          Knut Anders Hatlen added a comment - I'd prefer that we don't change the behaviour of StandardException.printStackTrace(), as that may be confusing to the users and may also make the output from the applications noisy and harder to read. To me it sounds sufficient to dump this information to derby.log and not include the thread dump in the exception itself. What about adding the code to ContextManager.cleanupOnError() instead? That's where the writing of errors to derby.log happens.
          Hide
          Bryan Pendleton added a comment -

          +1 to placing this information in a file of some sort.

          derby.log is a reasonable suggestion.

          Another idea is create a separate file JUST for this this crash information.
          Since it's similar in notion to a "crash dump" file, how about a uniquely
          generated name for a standalone "dump" file of some sort, as in:

          derby_minidump_YYMMDD_n.txt

          Where the YYMMDD is today's date, and the 'N' is
          a number incremented each time we produce a dump on
          that date.

          A nicely packaged standalone dump file produced on a system crash
          would provide a very helpful tool for users to interact with the
          community when trying to diagnose Derby problems.

          Show
          Bryan Pendleton added a comment - +1 to placing this information in a file of some sort. derby.log is a reasonable suggestion. Another idea is create a separate file JUST for this this crash information. Since it's similar in notion to a "crash dump" file, how about a uniquely generated name for a standalone "dump" file of some sort, as in: derby_minidump_YYMMDD_n.txt Where the YYMMDD is today's date, and the 'N' is a number incremented each time we produce a dump on that date. A nicely packaged standalone dump file produced on a system crash would provide a very helpful tool for users to interact with the community when trying to diagnose Derby problems.
          Hide
          Kristian Waagan added a comment -

          Another point supporting Bryan's suggestion, is that derby.log is by default overwritten.
          This can be, and hopefully is, changed in production environments, but I still think a separate file is an approach worth considering (we may have to deal with write privileges then).

          Show
          Kristian Waagan added a comment - Another point supporting Bryan's suggestion, is that derby.log is by default overwritten. This can be, and hopefully is, changed in production environments, but I still think a separate file is an approach worth considering (we may have to deal with write privileges then).
          Hide
          Lily Wei added a comment -

          We can definitely consider writing the information to a separate file and consider the deal with write privileges. If we do add the code in ContextManager.cleanupOnError(), how do we make sure the database is already boot. I keep seeing the threadDump information get print out before the database is booted. How to avoid it?

          Show
          Lily Wei added a comment - We can definitely consider writing the information to a separate file and consider the deal with write privileges. If we do add the code in ContextManager.cleanupOnError(), how do we make sure the database is already boot. I keep seeing the threadDump information get print out before the database is booted. How to avoid it?
          Hide
          Lily Wei added a comment - - edited

          Thanks to Kathey, due to the scope of the changes, I would like to purpose three steps check-in to address this issue :
          I.
          1.1. Move ThreadDump.java from java/shared/org/apache/derby/shared/common/sanity to java/shard/org/apache/derby/shared/common/error
          1.2. move dumpThreads method from AssertFailure to ExceptionUtil
          1.3 Have this available for insane build only.
          II.
          2.1 Add ThreadDump information to sane build in ContextManager. cleanupOnError(). it will print the thread dump information to derby.log
          III.
          3.1 Add file handling as Bryan and Kristian's suggestion for ThreadDump info. The current thinking is to add the file handling code as the method as utility tool and calls it in ContextManager

          I am attaching DERBY-4856-part_1_1a.diff for code review. The patching is covering the part one change. I am running Suites.All and derbyall now.

          Show
          Lily Wei added a comment - - edited Thanks to Kathey, due to the scope of the changes, I would like to purpose three steps check-in to address this issue : I. 1.1. Move ThreadDump.java from java/shared/org/apache/derby/shared/common/sanity to java/shard/org/apache/derby/shared/common/error 1.2. move dumpThreads method from AssertFailure to ExceptionUtil 1.3 Have this available for insane build only. II. 2.1 Add ThreadDump information to sane build in ContextManager. cleanupOnError(). it will print the thread dump information to derby.log III. 3.1 Add file handling as Bryan and Kristian's suggestion for ThreadDump info. The current thinking is to add the file handling code as the method as utility tool and calls it in ContextManager I am attaching DERBY-4856 -part_1_1a.diff for code review. The patching is covering the part one change. I am running Suites.All and derbyall now.
          Hide
          Bryan Pendleton added a comment -

          +1 to the technique of the multi-step approach.

          I read through your part-1 patch and it looks fine to me.

          Thanks for working on this infrastructure, it will be very helpful!

          Show
          Bryan Pendleton added a comment - +1 to the technique of the multi-step approach. I read through your part-1 patch and it looks fine to me. Thanks for working on this infrastructure, it will be very helpful!
          Hide
          Lily Wei added a comment -

          Thank you so much, Bryan. I run Suites.all and derbyall and I did not see any error. If it is okay with everybody, I will check into trunk today.

          Show
          Lily Wei added a comment - Thank you so much, Bryan. I run Suites.all and derbyall and I did not see any error. If it is okay with everybody, I will check into trunk today.
          Hide
          Knut Anders Hatlen added a comment -

          I think this is OK as long as the classes are only used by the sane jars. If you plan to use the classes in the production jars too, you should be aware of the discussion in DERBY-289, which raises some concerns about having code in the shared packages.

          Show
          Knut Anders Hatlen added a comment - I think this is OK as long as the classes are only used by the sane jars. If you plan to use the classes in the production jars too, you should be aware of the discussion in DERBY-289 , which raises some concerns about having code in the shared packages.
          Hide
          Kathey Marsden added a comment -

          I think the point of the move is to make them available for insane builds so they can be used by the engine on a crash, so if it cannot be in shared, I guess instead of moving the SanityManager code, there will have to be separate new code for producing thread dumps in java/engine/org/apache/derby/iapi/services/info. It would be good to include comments in both explaining that any bug fixes will likely have to be fixed in both places.

          Show
          Kathey Marsden added a comment - I think the point of the move is to make them available for insane builds so they can be used by the engine on a crash, so if it cannot be in shared, I guess instead of moving the SanityManager code, there will have to be separate new code for producing thread dumps in java/engine/org/apache/derby/iapi/services/info. It would be good to include comments in both explaining that any bug fixes will likely have to be fixed in both places.
          Hide
          Lily Wei added a comment -

          Thanks Knut and Kathey.
          For phrase one, the goal is to use ExceptionUtil.dumpThread() in AssertFailure.java. AssertFailure.java is in shared/common/sanity for insane build.
          For phrase two, the goal is to use ExceptionUtil.dumpThread() in ContextManager for engine. ExceptionUtil is in shared/common/error which is an existing class for derby.jar and derbyclient.jar. I am including ContextManaer.java now to help me understand does it fit into the David's concern on DERBY-289 https://issues.apache.org/jira/browse/DERBY-289?focusedCommentId=12415429&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12415429. If phrase two's change is only to ContextManager.java(working progress) which uses ExceptionUtil.java and ExceptionUtil.java is an existing class, do I still need to introduce code in java/engine/org/apache/derby/iapi/services/info to have similar class? I would think it is safe to use since it is an existing class on shared/common/error that derby.jar and derbyclient.jar both had.

          Show
          Lily Wei added a comment - Thanks Knut and Kathey. For phrase one, the goal is to use ExceptionUtil.dumpThread() in AssertFailure.java. AssertFailure.java is in shared/common/sanity for insane build. For phrase two, the goal is to use ExceptionUtil.dumpThread() in ContextManager for engine. ExceptionUtil is in shared/common/error which is an existing class for derby.jar and derbyclient.jar. I am including ContextManaer.java now to help me understand does it fit into the David's concern on DERBY-289 https://issues.apache.org/jira/browse/DERBY-289?focusedCommentId=12415429&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12415429 . If phrase two's change is only to ContextManager.java(working progress) which uses ExceptionUtil.java and ExceptionUtil.java is an existing class, do I still need to introduce code in java/engine/org/apache/derby/iapi/services/info to have similar class? I would think it is safe to use since it is an existing class on shared/common/error that derby.jar and derbyclient.jar both had.
          Hide
          Kathey Marsden added a comment -

          Hi Lily,

          I see what you mean about ExceptionUtil.java. I think the short story is that that it should not have ever been used by the engine. David's original comment said:

          "DERBY-838: Establish an internationalization framework for the network
          client.

          Added a new shared directory and shared packages. These shared packages
          are only used by the derbyclient.jar until we establish a shared code framework"

          I recall conversations long ago that until we figured out how to really handle common code, things that would be potentially good to share would be put under shared, but only be used by client until the whole framework was worked out. Unfortunately this history was lost when during the LOB work too years later, ExceptionUtil obviously looked very convenient for this engine work, but we should probably file a bug to take references to ExceptionUtil out of the engine.

          Show
          Kathey Marsden added a comment - Hi Lily, I see what you mean about ExceptionUtil.java. I think the short story is that that it should not have ever been used by the engine. David's original comment said: " DERBY-838 : Establish an internationalization framework for the network client. Added a new shared directory and shared packages. These shared packages are only used by the derbyclient.jar until we establish a shared code framework" I recall conversations long ago that until we figured out how to really handle common code, things that would be potentially good to share would be put under shared, but only be used by client until the whole framework was worked out. Unfortunately this history was lost when during the LOB work too years later, ExceptionUtil obviously looked very convenient for this engine work, but we should probably file a bug to take references to ExceptionUtil out of the engine.
          Hide
          Lily Wei added a comment -

          Thanks Kathey for point out the history and how to proceed. Thanks Knut for helping me on IRC. Due to the fact that java/shared/org/apache/derby/shared/common is really for derbyclient.jar. And, my part 1 and part 2 are really only for engine. I will not be changing the java/shared/org/apache/derby/shared/common/sanity/ThreadDump.java. or any of the shared files.
          Instead, I am adding a new java/engine/org/apache/derby/iapi/error/ThreadDumpUtil.java and java/engine/org/apache/derby/iapi/error/ExceptionUtil.java Since these two files are very similar to the ThreadDump.java and ExceptionUtil.java in java/shared/ . In the future, if the code affect both engine and client, developer has to fix in two places.

          I changed the name from ThreadDump.java to ThreadDumpUtil.java. If there is no extra instruction in extraDBMSclasses.properties or rename to ThreadDumpUtil.java, With the change iapi/build.xml, build process will always build ThreadDump.class in classes/org/apache/derby/shared/common/error/ThreadDump.class.
          With derby.module.engine.threaddumputil=org.apache.derby.iapi.error.ThreadDumpUtil in extraDBMSclasses.properties and rename ThreadDump.java to ThreadDumpUtil.java in iapi/error, the build process will build classes/org/apache/derby/iapi/error/ThreadDumpUtil.class

          ContextManager.java change is so thread dump information will be in insane build. I install updates for eclipse with my eclipse. The new behavior keeps sorting the import files when I press safe. I tried to make it not sort the import files and not very successful. I thought we can use sorted import files. If we prefer not to have it sort, I need help to figure out how to make eclipse not sort the import files.

          The code is ready for review. I run Suites.all and derybyall for insane and sane build and they all run okay. I also tested it with 'corruptdb' database and see the thread dump information.

          Show
          Lily Wei added a comment - Thanks Kathey for point out the history and how to proceed. Thanks Knut for helping me on IRC. Due to the fact that java/shared/org/apache/derby/shared/common is really for derbyclient.jar. And, my part 1 and part 2 are really only for engine. I will not be changing the java/shared/org/apache/derby/shared/common/sanity/ThreadDump.java. or any of the shared files. Instead, I am adding a new java/engine/org/apache/derby/iapi/error/ThreadDumpUtil.java and java/engine/org/apache/derby/iapi/error/ExceptionUtil.java Since these two files are very similar to the ThreadDump.java and ExceptionUtil.java in java/shared/ . In the future, if the code affect both engine and client, developer has to fix in two places. I changed the name from ThreadDump.java to ThreadDumpUtil.java. If there is no extra instruction in extraDBMSclasses.properties or rename to ThreadDumpUtil.java, With the change iapi/build.xml, build process will always build ThreadDump.class in classes/org/apache/derby/shared/common/error/ThreadDump.class. With derby.module.engine.threaddumputil=org.apache.derby.iapi.error.ThreadDumpUtil in extraDBMSclasses.properties and rename ThreadDump.java to ThreadDumpUtil.java in iapi/error, the build process will build classes/org/apache/derby/iapi/error/ThreadDumpUtil.class ContextManager.java change is so thread dump information will be in insane build. I install updates for eclipse with my eclipse. The new behavior keeps sorting the import files when I press safe. I tried to make it not sort the import files and not very successful. I thought we can use sorted import files. If we prefer not to have it sort, I need help to figure out how to make eclipse not sort the import files. The code is ready for review. I run Suites.all and derybyall for insane and sane build and they all run okay. I also tested it with 'corruptdb' database and see the thread dump information.
          Hide
          Kathey Marsden added a comment -

          Thanks Lily for the patch.

          For the new engine ExceptionUtil, I don't think the field threadDump is needed or used. The reflection call should use the ThreadDump in engine, not the shared one. I think then it will be fine for the engine ThreadDump class to keep the original name, ThreadDump.

          In ContextManager, there seem to be some javadoc formatting issues with the new getErrorCode method, which might better be callse dgetErrorSeverity. I would add a comment that errors that are not Standard or SQLExcetions are not handled at this time.
          ]

          Show
          Kathey Marsden added a comment - Thanks Lily for the patch. For the new engine ExceptionUtil, I don't think the field threadDump is needed or used. The reflection call should use the ThreadDump in engine, not the shared one. I think then it will be fine for the engine ThreadDump class to keep the original name, ThreadDump. In ContextManager, there seem to be some javadoc formatting issues with the new getErrorCode method, which might better be callse dgetErrorSeverity. I would add a comment that errors that are not Standard or SQLExcetions are not handled at this time. ]
          Hide
          Lily Wei added a comment -

          Thanks Kathey for reviewing the code.
          I attached the part_2_2b patch.
          The threadDump varilable is removed from ExceptionUtil and the reflection is using ThreadDump. The ThreadDumpUtil is rename to ThreadDump in iapi/error.

          In ContextManager, the import is not being sorted. The getErrorCode Method is renamed to getErrorSeverity and the javadoc format issues is modified. Add commend says error only StandardException and SQLException are being handled at this time.

          build.xml and extraDBMSclasses.properties had been changed to reflect rename of ThreadDumpUtil to ThreadDump.

          Show
          Lily Wei added a comment - Thanks Kathey for reviewing the code. I attached the part_2_2b patch. The threadDump varilable is removed from ExceptionUtil and the reflection is using ThreadDump. The ThreadDumpUtil is rename to ThreadDump in iapi/error. In ContextManager, the import is not being sorted. The getErrorCode Method is renamed to getErrorSeverity and the javadoc format issues is modified. Add commend says error only StandardException and SQLException are being handled at this time. build.xml and extraDBMSclasses.properties had been changed to reflect rename of ThreadDumpUtil to ThreadDump.
          Hide
          Lily Wei added a comment -

          Run fine for suites.all and derbyall for insane build. Thread dump info is log to derby.log.
          Commit fix for part 2 of this issue and DERBY-4929 at subversion revision 1043290.

          Show
          Lily Wei added a comment - Run fine for suites.all and derbyall for insane build. Thread dump info is log to derby.log. Commit fix for part 2 of this issue and DERBY-4929 at subversion revision 1043290.
          Hide
          Knut Anders Hatlen added a comment -

          The two new files added in the patch didn't have the svn:eol-style property set. I fixed that and committed revision 1043334.

          Here's a description of how to configure Subversion to set this property automatically for you: http://www.apache.org/dev/svn-eol-style.txt

          Show
          Knut Anders Hatlen added a comment - The two new files added in the patch didn't have the svn:eol-style property set. I fixed that and committed revision 1043334. Here's a description of how to configure Subversion to set this property automatically for you: http://www.apache.org/dev/svn-eol-style.txt
          Hide
          Lily Wei added a comment -

          Thanks to Kathey. I am attach DERBY-4856_part_3_1a.diff patch.
          The changes in this patch:
          1. Allow use enter property derby.stream.error.extendedDiagSeverityLevel. The default value is 40000
          2. If the error(StandardException, SQLException) has error severity level >= derby.stream.error.extendedDiagSeverityLevel, thread dump information and extend diagnosis information will be handle by Derby.
          3. Change SimpleTest to have derby.stream.error.extendedDiagSeverityLevel=45000

          I am running Suites and derbyall tests now.

          Question: If the database is not booted and error occurs, thread dump information and extend diagnosis information will still be handle with proper extenedDiagSeverityLevel . Should the code be some where else than ContextManager.cleanupOnError()? Any suggestion is welcome. Thanks.

          Show
          Lily Wei added a comment - Thanks to Kathey. I am attach DERBY-4856 _part_3_1a.diff patch. The changes in this patch: 1. Allow use enter property derby.stream.error.extendedDiagSeverityLevel. The default value is 40000 2. If the error(StandardException, SQLException) has error severity level >= derby.stream.error.extendedDiagSeverityLevel, thread dump information and extend diagnosis information will be handle by Derby. 3. Change SimpleTest to have derby.stream.error.extendedDiagSeverityLevel=45000 I am running Suites and derbyall tests now. Question: If the database is not booted and error occurs, thread dump information and extend diagnosis information will still be handle with proper extenedDiagSeverityLevel . Should the code be some where else than ContextManager.cleanupOnError()? Any suggestion is welcome. Thanks.
          Hide
          Lily Wei added a comment -

          Thanks to IRC discussion with Kathey and Knut. This is the prototype for checking whether database is active or it is okay to trace thread dump information in ContextManager.cleanupOnError on top of part_3_1a patch. The change includes:
          1. cleanupOnError takes two parameters: error and isdbactive. If isdbactive, it will print out threadudmp info and diagnosis information for ibm jvm
          2. The guide line to get isdbactive information is to just pass the Boolean value when it make sense, get it from the isactive information from the database associated with the object, get it from the isactive Boolean value from the database associated with LanguageConnectionContext, or the isactive value from EmbedPooledConnection value.

          The patch passed Suites.all and derbyall for sun jvm. However, it hangs on replication tests for ibm jvm such as ReplicationRun_Local in ReplicationRun_Local.connectPing somewhere near conn=DriverManager.getConnection(dbURL);

          The patch is ready for review. Thank you for reviewing in advance.

          Show
          Lily Wei added a comment - Thanks to IRC discussion with Kathey and Knut. This is the prototype for checking whether database is active or it is okay to trace thread dump information in ContextManager.cleanupOnError on top of part_3_1a patch. The change includes: 1. cleanupOnError takes two parameters: error and isdbactive. If isdbactive, it will print out threadudmp info and diagnosis information for ibm jvm 2. The guide line to get isdbactive information is to just pass the Boolean value when it make sense, get it from the isactive information from the database associated with the object, get it from the isactive Boolean value from the database associated with LanguageConnectionContext, or the isactive value from EmbedPooledConnection value. The patch passed Suites.all and derbyall for sun jvm. However, it hangs on replication tests for ibm jvm such as ReplicationRun_Local in ReplicationRun_Local.connectPing somewhere near conn=DriverManager.getConnection(dbURL); The patch is ready for review. Thank you for reviewing in advance.
          Hide
          Lily Wei added a comment -

          Thanks to Kathey for reviewing the code. The new patch is ready for review.
          Change in this patch compare to last one
          1. For all the tests, assume we don't want the thread dump info except T_b2i.java test. For T_b2i.java, I am testing the test can function correctly if we get the database active information from LanguageConnectionContext object.
          2. For the code path we know it is okay not to get the thread dump information, we will assume database is not active
          3. Change getSystenProperty to private in JVMInfo.java

          Patch run clean on suites.all for sun jvm. I am still running derbyall test suite for sun jvm.

          There are two issues that are under investigation:
          1. For ibm 1.6 jvm, ReplicationRun_Local still hang on ReplicationRun.connectPing(...) where we try to do DriverManager.getConnection(dbURL) on windows 7. The test did not hang with ibm 1.6 jvm on windows xp. The dbURL value is jdbc:derby://localhost:1531/c:\derby3\trunk\testtmp\db_slave\wombat I am thinking out loud here. Will change the path for the master and slave server and using the new way to remove directory make the hang issue and intermediate failure on replication tests behave better? Any suggestion is welcome.
          2. For replication failover case, there are some javacore* files created due to the current design of handling javaDump for ibm. Maybe we should just not dump thread info in these cases?

          Happy New Year!

          Show
          Lily Wei added a comment - Thanks to Kathey for reviewing the code. The new patch is ready for review. Change in this patch compare to last one 1. For all the tests, assume we don't want the thread dump info except T_b2i.java test. For T_b2i.java, I am testing the test can function correctly if we get the database active information from LanguageConnectionContext object. 2. For the code path we know it is okay not to get the thread dump information, we will assume database is not active 3. Change getSystenProperty to private in JVMInfo.java Patch run clean on suites.all for sun jvm. I am still running derbyall test suite for sun jvm. There are two issues that are under investigation: 1. For ibm 1.6 jvm, ReplicationRun_Local still hang on ReplicationRun.connectPing(...) where we try to do DriverManager.getConnection(dbURL) on windows 7. The test did not hang with ibm 1.6 jvm on windows xp. The dbURL value is jdbc:derby://localhost:1531/c:\derby3\trunk\testtmp\db_slave\wombat I am thinking out loud here. Will change the path for the master and slave server and using the new way to remove directory make the hang issue and intermediate failure on replication tests behave better? Any suggestion is welcome. 2. For replication failover case, there are some javacore* files created due to the current design of handling javaDump for ibm. Maybe we should just not dump thread info in these cases? Happy New Year!
          Hide
          Lily Wei added a comment -

          Change in this patch compare to 3a patch:
          1. Change TransactionResourceImpl.cleanupOnError(Throwable e) to assume database is not active to avoid the hanging problem for replicationRun_Local test one windows 7. Also, not create thread dump info and diagnoisis files on replication failover situation.

          Suites.all runs clean with ibm 1.6 jvm with svn 1054737. derbyall failed on unit/T_RawStoreFactory.unit due to not able to shutdown database.

          Suites.all and derbyall run clean with sun jvm.

          The patch is ready for review.

          Show
          Lily Wei added a comment - Change in this patch compare to 3a patch: 1. Change TransactionResourceImpl.cleanupOnError(Throwable e) to assume database is not active to avoid the hanging problem for replicationRun_Local test one windows 7. Also, not create thread dump info and diagnoisis files on replication failover situation. Suites.all runs clean with ibm 1.6 jvm with svn 1054737. derbyall failed on unit/T_RawStoreFactory.unit due to not able to shutdown database. Suites.all and derbyall run clean with sun jvm. The patch is ready for review.
          Hide
          Lily Wei added a comment -

          Thanks to Kathey for reviewing the code and found problem for not able to get thread dump and diagnostic information when there is deadlock error. Please refer to test Derby3980DeadlockTest.

          The changes for this patch compare to 3b are:
          1. Use isactive variable in SequenceUpdater.java
          2. Revise TransactionResourceImpl.cleanupOnError(Throwable error, Boolean diagActive) method to take one more parameter to further detect whether to process diagnostic information.
          • Pass whether database is active information in TransactionResourceImpl.handleException
          3. Assume database is not active when calling TransactionResourceImpl.cleanupOnError on EmbeddedConnection(...) init stage and EmbeddedConnection.close
          4. Change comments and variable name
          5. Add test to Derby3980DeadlockTest.java

          Current result: There is one javacore* file after Derby3980DeadlockTest

          I am running suites.all and derbyall tests. Please review the code.

          Show
          Lily Wei added a comment - Thanks to Kathey for reviewing the code and found problem for not able to get thread dump and diagnostic information when there is deadlock error. Please refer to test Derby3980DeadlockTest. The changes for this patch compare to 3b are: 1. Use isactive variable in SequenceUpdater.java 2. Revise TransactionResourceImpl.cleanupOnError(Throwable error, Boolean diagActive) method to take one more parameter to further detect whether to process diagnostic information. • Pass whether database is active information in TransactionResourceImpl.handleException 3. Assume database is not active when calling TransactionResourceImpl.cleanupOnError on EmbeddedConnection(...) init stage and EmbeddedConnection.close 4. Change comments and variable name 5. Add test to Derby3980DeadlockTest.java Current result: There is one javacore* file after Derby3980DeadlockTest I am running suites.all and derbyall tests. Please review the code.
          Hide
          Lily Wei added a comment -

          After running derbyall and suites.all with ibm 1.6 jvm, I made the following adjustment and attach 3d patch:
          1. Check whether database is null at TransactionResourceImple.handleException as sometimes the database can be null and we will not want to print any thread dump or diagnostic information
          2. Modify MaxLogNumberRecovery.java to set derby.stream.error.extendedDiagSeverityLevel to 50000 so no thread dump or diagnostic information as test exceed the max log file number.
          3. Revert the change for SimpleTest.java since the flag value is being used in Derby3980DeadlockTest and MaxLogNumberRecovery.

          Derbyall and suites.all does not have any unexpected failure with ibm 1.6 jvm. I am running with sun jvm now. The patch is ready for review.

          Show
          Lily Wei added a comment - After running derbyall and suites.all with ibm 1.6 jvm, I made the following adjustment and attach 3d patch: 1. Check whether database is null at TransactionResourceImple.handleException as sometimes the database can be null and we will not want to print any thread dump or diagnostic information 2. Modify MaxLogNumberRecovery.java to set derby.stream.error.extendedDiagSeverityLevel to 50000 so no thread dump or diagnostic information as test exceed the max log file number. 3. Revert the change for SimpleTest.java since the flag value is being used in Derby3980DeadlockTest and MaxLogNumberRecovery. Derbyall and suites.all does not have any unexpected failure with ibm 1.6 jvm. I am running with sun jvm now. The patch is ready for review.
          Hide
          Lily Wei added a comment -

          Add removing the javacore* file from Derby3980DeadlockTest and add the proper .policy file for it.
          However, due to the current behavior regarding error for 40001 or 40XL1: A lock could not be obtained. The test output is different from ibm jvm or sun jvm. There might be more work to be done to make the test more stable to be part of regression test. There is no change on code change for 3e patch. Suites and derbyall run clean on 3e patch.

          Show
          Lily Wei added a comment - Add removing the javacore* file from Derby3980DeadlockTest and add the proper .policy file for it. However, due to the current behavior regarding error for 40001 or 40XL1: A lock could not be obtained. The test output is different from ibm jvm or sun jvm. There might be more work to be done to make the test more stable to be part of regression test. There is no change on code change for 3e patch. Suites and derbyall run clean on 3e patch.
          Hide
          Lily Wei added a comment -

          Thanks to Kathey, patch 3g modify Derby3980DeadlockTest.decorateTest to preserve the derby.log on failure. Due to extra timing to create javacore* files, ibm jvm produce deadlock error instead of log time out error.

          Show
          Lily Wei added a comment - Thanks to Kathey, patch 3g modify Derby3980DeadlockTest.decorateTest to preserve the derby.log on failure. Due to extra timing to create javacore* files, ibm jvm produce deadlock error instead of log time out error.
          Hide
          Lily Wei added a comment -

          Check in svn #1058404 for part_3_3g patch with space/tab changes and AuthenticationTest.java change.
          It is possible the database.isActive() information could need more work. Please watch that for me. When running suites.all with ibm jvm, there are left over javacore* files. I still need to do clean up work. More information is needed to find out which tests create the javacore*file. There are two ways to clean up the javacore* files - create teardown() method to clean up the javacore* files or set the flag by calling
          setSystemProperty("derby.stream.error.extendedDiagSeverityLevel","50000")

          Derby3980DeadlockTest might not always produce deadlock error and it is not part of nightly run test.

          Thank Kathey so much for keep helping me review and write this part of fix. Thank Knut for giving very helpful tips in IRC and everywhere else. Hopefully, the javacore* files will not cause the machine to run out of disk space. Post-commit reviews still welcome.

          Show
          Lily Wei added a comment - Check in svn #1058404 for part_3_3g patch with space/tab changes and AuthenticationTest.java change. It is possible the database.isActive() information could need more work. Please watch that for me. When running suites.all with ibm jvm, there are left over javacore* files. I still need to do clean up work. More information is needed to find out which tests create the javacore*file. There are two ways to clean up the javacore* files - create teardown() method to clean up the javacore* files or set the flag by calling setSystemProperty("derby.stream.error.extendedDiagSeverityLevel","50000") Derby3980DeadlockTest might not always produce deadlock error and it is not part of nightly run test. Thank Kathey so much for keep helping me review and write this part of fix. Thank Knut for giving very helpful tips in IRC and everywhere else. Hopefully, the javacore* files will not cause the machine to run out of disk space. Post-commit reviews still welcome.
          Hide
          Knut Anders Hatlen added a comment -

          It would be good to add a comment in AuthenticationTest to explain why the system property has to be set for the test. There's no code to reset the property, so doesn't that mean it will affect subsequent tests too? Thinking more about it, since the code to set the system property is in baseSuite(), it will be executed before any tests have started, so it will probably affect all the tests. Would it work to wrap the test in a SystemPropertyTestSetup instead?

          Show
          Knut Anders Hatlen added a comment - It would be good to add a comment in AuthenticationTest to explain why the system property has to be set for the test. There's no code to reset the property, so doesn't that mean it will affect subsequent tests too? Thinking more about it, since the code to set the system property is in baseSuite(), it will be executed before any tests have started, so it will probably affect all the tests. Would it work to wrap the test in a SystemPropertyTestSetup instead?
          Hide
          Lily Wei added a comment -

          Thanks Knut for reviewing. I will add the comment to explain why the system property has to be set for AuthenticationTest. When I run suites.all with 1.6 ibm jvm, it created 145 javacore* files. I review most of them and most of them come from AuthenticationTest for getConnection that will get error/SQLException with negative tests. So, it makes sense for the thread dump information and diagnostic information. However, we really don't want to have too many left over javacore* files after test run. So, I set it in baseSuite() to trigger not producing such behavior. I will look into wrap the test in a SystemPropertyTestSetup to see whether it is more appropriate.

          Show
          Lily Wei added a comment - Thanks Knut for reviewing. I will add the comment to explain why the system property has to be set for AuthenticationTest. When I run suites.all with 1.6 ibm jvm, it created 145 javacore* files. I review most of them and most of them come from AuthenticationTest for getConnection that will get error/SQLException with negative tests. So, it makes sense for the thread dump information and diagnostic information. However, we really don't want to have too many left over javacore* files after test run. So, I set it in baseSuite() to trigger not producing such behavior. I will look into wrap the test in a SystemPropertyTestSetup to see whether it is more appropriate.
          Hide
          Lily Wei added a comment -

          It is better to wrap extendedDiagSeverityLevel property in SystemPropertyTestSetup for AuthenticationTest. Add the comment and the change to DERBY-4856_part_3_3g_1a.diff patch. I am running suites.All to see we don't produce too many javacore* files. Please review the change.

          Show
          Lily Wei added a comment - It is better to wrap extendedDiagSeverityLevel property in SystemPropertyTestSetup for AuthenticationTest. Add the comment and the change to DERBY-4856 _part_3_3g_1a.diff patch. I am running suites.All to see we don't produce too many javacore* files. Please review the change.
          Hide
          Lily Wei added a comment -

          Thanks Kathey for giving her blessing for DERBY-4856_part_3_3g_1a.diff patch. There is only one javacore* file left after running suites.all with ibm 1.6 jvm. The test runs clean. The file is from LockInterruptTest. Add property to avoid thread dump and diagnostic information with DERBY-4856_part_3_3g_2a.diff patch. Please review the code.

          Show
          Lily Wei added a comment - Thanks Kathey for giving her blessing for DERBY-4856 _part_3_3g_1a.diff patch. There is only one javacore* file left after running suites.all with ibm 1.6 jvm. The test runs clean. The file is from LockInterruptTest. Add property to avoid thread dump and diagnostic information with DERBY-4856 _part_3_3g_2a.diff patch. Please review the code.
          Hide
          Kathey Marsden added a comment -

          Lilly at what point in the test was the the javacore occurring? Was it really a crash?

          Show
          Kathey Marsden added a comment - Lilly at what point in the test was the the javacore occurring? Was it really a crash?
          Hide
          Lily Wei added a comment -

          Thanks Kathey for reviewing. At LockInterruptTest.runWaiter() line 150 with ps.executeUpdate, the test receive an interrupt and raise an error/exception "ERROR 08000: Connection closed by unknown interrupt". I think this is a negative test case again. So, I set the flag to turn off thread dump and diagnostic information.

          Show
          Lily Wei added a comment - Thanks Kathey for reviewing. At LockInterruptTest.runWaiter() line 150 with ps.executeUpdate, the test receive an interrupt and raise an error/exception "ERROR 08000: Connection closed by unknown interrupt". I think this is a negative test case again. So, I set the flag to turn off thread dump and diagnostic information.
          Hide
          Kathey Marsden added a comment -

          I think this is indeed a session ending exception so it makes sense to get the javadump when it occurs and the thread dump might be very useful at this point. If under some circumstance someone had intentional interrupts where this was expected, they could set property higher to avoid the javacores, so +1 to the change.

          Show
          Kathey Marsden added a comment - I think this is indeed a session ending exception so it makes sense to get the javadump when it occurs and the thread dump might be very useful at this point. If under some circumstance someone had intentional interrupts where this was expected, they could set property higher to avoid the javacores, so +1 to the change.
          Hide
          Lily Wei added a comment -

          Thanks Kathey for reviewing. I'll check-in the patch now.

          Show
          Lily Wei added a comment - Thanks Kathey for reviewing. I'll check-in the patch now.
          Hide
          Lily Wei added a comment -

          Attach the releaseNote.html. Please review the release note.

          Show
          Lily Wei added a comment - Attach the releaseNote.html. Please review the release note.
          Hide
          Dag H. Wanvik added a comment -

          Hi, thanks for the release notes, Lily!

          Caveat, my comments below are not based on a thorough knowledge of
          this new feature, I have just read about if cursorily, so if I got my
          fact wrong, please forgive. Mostly, my change proposals are for
          improved legibility.

          > Summary of Change
          >
          > Derby will dump as much thread dump and diagnostic information as
          > possible on system crash or session error. i.e. Users will find
          > thread dump information with error severity higher than session
          > error in derby.log.

          "will" -> "will by default"
          "Users" -> "users"

          Maybe add a sentence: "It is also possible to get thread dump and
          diagnostic information" of errors with lower severity by adjusting a
          property".

          > Symptoms Seen by Applications Affected by
          > Change
          >
          > If errors have error severity level greater or equal than value
          > derby.stream.error.extendedDiagSeverityLevel is set, thread dump
          > information and extened diagnostic information will be handle by
          > Derby. Users can find thread dump information on derby.log. For ibm
          > jvm users, a javacore file will be created.

          I am not sure this content is correct for this section: The "symptom"
          if any of existing systems would be that we don't get (or there is not
          way to get ) enough state information when the system crashes or a
          session level error happens.

          > Incompatibilities with Previous Release
          >
          > N/A

          "N/A -> None

          I think "none" is better here, since incompatibilities is always a
          relevant ("applicable") question for database changes.

          > Rationale for Change
          >
          > The change intend to get more detail information relate to the staus

          "The change intend" -> The intention of the change
          "staus" -> status

          > of Derby server when user hit system crash or server session error.

          "Derby server" -> This applies to embedded usages as well? (i.e. not
          limited to running with client/server. If so, maybe you can just use
          "Derby" instead.

          > Application Changes Required
          >
          > Users do not need to change anything for this change. If more thread
          > dump information requires for error is has severity level less than

          "requires" -> "is required"
          "is has" -> that have"

          > session error, derby.stream.error.extendedDiagSeverityLevel can be

          Specify scope (database or system level) of property and whether it is
          a dynamic or static property.

          > set on derby.properties or as part of jvm argument. For example, if

          "on derby.properties" -> in the file "derby.properties"
          "jvm" -> "JVM"

          > there is a deadlock issue and users would like to see thread dump
          > information while deadlock is happening. Users can then set

          2nd "deadlock" above -> "the deadlock"

          ". Users" -> ", users"

          > derby.stream.error.extendedDiagSeverityLevel=30000 on either

          "on" -> "in"

          > derby.properties or as part of jvm argument.

          "jvm argument" -> "JVM argument, e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000"

          > They can find the tread dump information on derby.log.

          Change to "The thread dump information is found in the Derby error
          log, typically this is the file "derby.log".

          > derby.stream.error.extendedDiagSeverityLevel=30000 means
          > turn on TRANSACTION_SEVERITY type of error.

          last line -> "that the extended thread dump information for errors of
          transaction severity or higher. Please consult the Derby documentation for explanation of error severity and for
          other possible settings of extendedDiagSeverityLevel.

          Show
          Dag H. Wanvik added a comment - Hi, thanks for the release notes, Lily! Caveat, my comments below are not based on a thorough knowledge of this new feature, I have just read about if cursorily, so if I got my fact wrong, please forgive. Mostly, my change proposals are for improved legibility. > Summary of Change > > Derby will dump as much thread dump and diagnostic information as > possible on system crash or session error. i.e. Users will find > thread dump information with error severity higher than session > error in derby.log. "will" -> "will by default" "Users" -> "users" Maybe add a sentence: "It is also possible to get thread dump and diagnostic information" of errors with lower severity by adjusting a property". > Symptoms Seen by Applications Affected by > Change > > If errors have error severity level greater or equal than value > derby.stream.error.extendedDiagSeverityLevel is set, thread dump > information and extened diagnostic information will be handle by > Derby. Users can find thread dump information on derby.log. For ibm > jvm users, a javacore file will be created. I am not sure this content is correct for this section: The "symptom" if any of existing systems would be that we don't get (or there is not way to get ) enough state information when the system crashes or a session level error happens. > Incompatibilities with Previous Release > > N/A "N/A -> None I think "none" is better here, since incompatibilities is always a relevant ("applicable") question for database changes. > Rationale for Change > > The change intend to get more detail information relate to the staus "The change intend" -> The intention of the change "staus" -> status > of Derby server when user hit system crash or server session error. "Derby server" -> This applies to embedded usages as well? (i.e. not limited to running with client/server. If so, maybe you can just use "Derby" instead. > Application Changes Required > > Users do not need to change anything for this change. If more thread > dump information requires for error is has severity level less than "requires" -> "is required" "is has" -> that have" > session error, derby.stream.error.extendedDiagSeverityLevel can be Specify scope (database or system level) of property and whether it is a dynamic or static property. > set on derby.properties or as part of jvm argument. For example, if "on derby.properties" -> in the file "derby.properties" "jvm" -> "JVM" > there is a deadlock issue and users would like to see thread dump > information while deadlock is happening. Users can then set 2nd "deadlock" above -> "the deadlock" ". Users" -> ", users" > derby.stream.error.extendedDiagSeverityLevel=30000 on either "on" -> "in" > derby.properties or as part of jvm argument. "jvm argument" -> "JVM argument, e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000" > They can find the tread dump information on derby.log. Change to "The thread dump information is found in the Derby error log, typically this is the file "derby.log". > derby.stream.error.extendedDiagSeverityLevel=30000 means > turn on TRANSACTION_SEVERITY type of error. last line -> "that the extended thread dump information for errors of transaction severity or higher. Please consult the Derby documentation for explanation of error severity and for other possible settings of extendedDiagSeverityLevel.
          Hide
          Lily Wei added a comment -

          Thanks for the reviewing the release notes, Dag!!!

          Caveat, my comments below are not based on a thorough knowledge of
          this new feature, I have just read about if cursorily, so if I got my
          fact wrong, please forgive. Mostly, my change proposals are for
          improved legibility.
          You are so kind. I really appreciated.
          My comments are as follow:

          > Summary of Change
          >
          > Derby will dump as much thread dump and diagnostic information as
          > possible on system crash or session error. i.e. Users will find
          > thread dump information with error severity higher than session
          > error in derby.log.

          "will" -> "will by default"
          "Users" -> "users"
          These have been changed.

          Maybe add a sentence: "It is also possible to get thread dump and
          diagnostic information" of errors with lower severity by adjusting a
          property".
          I think I did this. However, if it still need adjustment, please just let me knows.

          > Symptoms Seen by Applications Affected by
          > Change
          >
          > If errors have error severity level greater or equal than value
          > derby.stream.error.extendedDiagSeverityLevel is set, thread dump
          > information and extened diagnostic information will be handle by
          > Derby. Users can find thread dump information on derby.log. For ibm
          > jvm users, a javacore file will be created.

          I am not sure this content is correct for this section: The "symptom"
          if any of existing systems would be that we don't get (or there is not
          way to get ) enough state information when the system crashes or a
          session level error happens.
          I am not sure about the content either. However, for this version, I decide to have the description here.
          If users only view this section of release note, it might be good to have the information here too.

          > Incompatibilities with Previous Release
          >
          > N/A

          "N/A -> None
          I changed this to "None".

          I think "none" is better here, since incompatibilities is always a
          relevant ("applicable") question for database changes.
          +1

          > Rationale for Change
          >
          > The change intend to get more detail information relate to the staus

          "The change intend" -> The intention of the change
          "staus" -> status

          > of Derby server when user hit system crash or server session error.

          "Derby server" -> This applies to embedded usages as well? (i.e. not
          limited to running with client/server. If so, maybe you can just use
          "Derby" instead.
          These have been changed.

          > Application Changes Required
          >
          > Users do not need to change anything for this change. If more thread
          > dump information requires for error is has severity level less than

          "requires" -> "is required"
          "is has" -> that have"

          > session error, derby.stream.error.extendedDiagSeverityLevel can be

          Specify scope (database or system level) of property and whether it is
          a dynamic or static property.

          > set on derby.properties or as part of jvm argument. For example, if

          "on derby.properties" -> in the file "derby.properties"
          "jvm" -> "JVM"

          > there is a deadlock issue and users would like to see thread dump
          > information while deadlock is happening. Users can then set

          2nd "deadlock" above -> "the deadlock"

          ". Users" -> ", users"

          > derby.stream.error.extendedDiagSeverityLevel=30000 on either

          "on" -> "in"

          > derby.properties or as part of jvm argument.

          "jvm argument" -> "JVM argument, e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000"

          > They can find the tread dump information on derby.log.

          Change to "The thread dump information is found in the Derby error
          log, typically this is the file "derby.log".

          > derby.stream.error.extendedDiagSeverityLevel=30000 means
          > turn on TRANSACTION_SEVERITY type of error.

          last line -> "that the extended thread dump information for errors of
          transaction severity or higher. Please consult the Derby documentation for explanation of error severity and for
          other possible settings of extendedDiagSeverityLevel.

          These have been changed.

          Show
          Lily Wei added a comment - Thanks for the reviewing the release notes, Dag!!! Caveat, my comments below are not based on a thorough knowledge of this new feature, I have just read about if cursorily, so if I got my fact wrong, please forgive. Mostly, my change proposals are for improved legibility. You are so kind. I really appreciated. My comments are as follow: > Summary of Change > > Derby will dump as much thread dump and diagnostic information as > possible on system crash or session error. i.e. Users will find > thread dump information with error severity higher than session > error in derby.log. "will" -> "will by default" "Users" -> "users" These have been changed. Maybe add a sentence: "It is also possible to get thread dump and diagnostic information" of errors with lower severity by adjusting a property". I think I did this. However, if it still need adjustment, please just let me knows. > Symptoms Seen by Applications Affected by > Change > > If errors have error severity level greater or equal than value > derby.stream.error.extendedDiagSeverityLevel is set, thread dump > information and extened diagnostic information will be handle by > Derby. Users can find thread dump information on derby.log. For ibm > jvm users, a javacore file will be created. I am not sure this content is correct for this section: The "symptom" if any of existing systems would be that we don't get (or there is not way to get ) enough state information when the system crashes or a session level error happens. I am not sure about the content either. However, for this version, I decide to have the description here. If users only view this section of release note, it might be good to have the information here too. > Incompatibilities with Previous Release > > N/A "N/A -> None I changed this to "None". I think "none" is better here, since incompatibilities is always a relevant ("applicable") question for database changes. +1 > Rationale for Change > > The change intend to get more detail information relate to the staus "The change intend" -> The intention of the change "staus" -> status > of Derby server when user hit system crash or server session error. "Derby server" -> This applies to embedded usages as well? (i.e. not limited to running with client/server. If so, maybe you can just use "Derby" instead. These have been changed. > Application Changes Required > > Users do not need to change anything for this change. If more thread > dump information requires for error is has severity level less than "requires" -> "is required" "is has" -> that have" > session error, derby.stream.error.extendedDiagSeverityLevel can be Specify scope (database or system level) of property and whether it is a dynamic or static property. > set on derby.properties or as part of jvm argument. For example, if "on derby.properties" -> in the file "derby.properties" "jvm" -> "JVM" > there is a deadlock issue and users would like to see thread dump > information while deadlock is happening. Users can then set 2nd "deadlock" above -> "the deadlock" ". Users" -> ", users" > derby.stream.error.extendedDiagSeverityLevel=30000 on either "on" -> "in" > derby.properties or as part of jvm argument. "jvm argument" -> "JVM argument, e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000" > They can find the tread dump information on derby.log. Change to "The thread dump information is found in the Derby error log, typically this is the file "derby.log". > derby.stream.error.extendedDiagSeverityLevel=30000 means > turn on TRANSACTION_SEVERITY type of error. last line -> "that the extended thread dump information for errors of transaction severity or higher. Please consult the Derby documentation for explanation of error severity and for other possible settings of extendedDiagSeverityLevel. These have been changed.
          Hide
          Dag H. Wanvik added a comment -

          Some further legibility improvement suggestions:

          > Summary of Change
          >
          > Derby will by default dump as much thread dump and diagnostic
          > information as possible on system crash or session error.
          > i.e. users will find thread dump information with error severity
          > higher than session error in derby.log.

          Possible improvement:

          On experiencing a system crash or session error, Derby will print as
          much diagnostic information as possible to the Derby error log,
          including stack traces of all threads.

          > It is also possible to get thread dump and diagnostic information of
          > errors with lower severity by adjusting a property.

          This one is good, maybe change "of" to "for",

          > Symptoms Seen by Applications Affected by Change

          > If errors have error severity level greater or equal than value
          > derby.stream.error.extendedDiagSeverityLevel is set, thread dump
          > information and extened diagnostic information will be handle by
          > Derby. Users can find thread dump information in derby.log. For ibm
          > JVM users, a javacore file will be created.

          I still feel this information belongs in the first section, and that
          this section should be N/A. I agree this is useful

          "handle" -> "printed"
          "in derby.log" -> "in the Derby error log"

          ibm -> IBM

          > Incompatibilities with Previous Release
          >
          > None

          > Rationale for Change
          >
          > The intention of the change to get more detail information relate to

          "relate" -> "related"

          > the status of Derby when user hit system crash or server session
          > error.

          Suggest_

          "the status of Derby when important errors happen, "important" by
          default meaning errors with session severity and higher. This will
          help users, DBAs and support personnel to determine the exact cause of
          the error condition."

          > Application Changes Required
          >
          > Users do not need to change anything for this change. If more thread
          > dump information is required for error that have severity level less
          > than session error, derby.stream.error.extendedDiagSeverityLevel can

          "derby.stream.error.extendedDiagSeverityLevel" ->
          "the property derby.stream.error.extendedDiagSeverityLevel"

          > be set in the file "derby.properties" or as part of the JVM
          > argument.

          In stead of specifying "derby.properties" or JVM argument here,
          wouldn't it be better to just state this is a Derby system property
          and give a link to the documentation? System wide properties can also
          be set programmatically. You could also say, here as an example, "for
          example, in derby.properties" but not try to enumerate all ways it can
          be set.

          http://db.apache.org/derby/docs/10.7/devguide/cdevsetprop16827.html

          > For example, if there is a deadlock issue and users would
          > like to see thread dump information while the deadlock is happening,
          > users can then set
          > derby.stream.error.extendedDiagSeverityLevel=30000 in the file
          > "derby.properties" or as part of JVM argument,
          > e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000.

          See above comment, drop how to to set it here altogether, just show
          the value required.

          > The thread dump information is found in the Derby error log,

          "The thread dump information" ->
          "The diagnostics and the thread dump information"

          > typically this is the file "derby.log".

          > derby.stream.error.extendedDiagSeverityLevel=30000
          > means turn on TRANSACTION_SEVERITY type of error that the extended
          > thread dump information for errors of transaction severity or
          > higher.

          Suggest:

          "derby.stream.error.extendedDiagSeverityLevel=30000 means that extra
          diagnostics and thread dump will be activated for errors with
          severity equal to og higher than transaction severity (30000)."

          > Please consult the Derby documentation for explanation of error
          > severity and for other possible settings of
          > extenedDiagSeverityLevel.

          Thanks,
          Dag

          Show
          Dag H. Wanvik added a comment - Some further legibility improvement suggestions: > Summary of Change > > Derby will by default dump as much thread dump and diagnostic > information as possible on system crash or session error. > i.e. users will find thread dump information with error severity > higher than session error in derby.log. Possible improvement: On experiencing a system crash or session error, Derby will print as much diagnostic information as possible to the Derby error log, including stack traces of all threads. > It is also possible to get thread dump and diagnostic information of > errors with lower severity by adjusting a property. This one is good, maybe change "of" to "for", > Symptoms Seen by Applications Affected by Change > If errors have error severity level greater or equal than value > derby.stream.error.extendedDiagSeverityLevel is set, thread dump > information and extened diagnostic information will be handle by > Derby. Users can find thread dump information in derby.log. For ibm > JVM users, a javacore file will be created. I still feel this information belongs in the first section, and that this section should be N/A. I agree this is useful "handle" -> "printed" "in derby.log" -> "in the Derby error log" ibm -> IBM > Incompatibilities with Previous Release > > None > Rationale for Change > > The intention of the change to get more detail information relate to "relate" -> "related" > the status of Derby when user hit system crash or server session > error. Suggest_ "the status of Derby when important errors happen, "important" by default meaning errors with session severity and higher. This will help users, DBAs and support personnel to determine the exact cause of the error condition." > Application Changes Required > > Users do not need to change anything for this change. If more thread > dump information is required for error that have severity level less > than session error, derby.stream.error.extendedDiagSeverityLevel can "derby.stream.error.extendedDiagSeverityLevel" -> "the property derby.stream.error.extendedDiagSeverityLevel" > be set in the file "derby.properties" or as part of the JVM > argument. In stead of specifying "derby.properties" or JVM argument here, wouldn't it be better to just state this is a Derby system property and give a link to the documentation? System wide properties can also be set programmatically. You could also say, here as an example, "for example, in derby.properties" but not try to enumerate all ways it can be set. http://db.apache.org/derby/docs/10.7/devguide/cdevsetprop16827.html > For example, if there is a deadlock issue and users would > like to see thread dump information while the deadlock is happening, > users can then set > derby.stream.error.extendedDiagSeverityLevel=30000 in the file > "derby.properties" or as part of JVM argument, > e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000. See above comment, drop how to to set it here altogether, just show the value required. > The thread dump information is found in the Derby error log, "The thread dump information" -> "The diagnostics and the thread dump information" > typically this is the file "derby.log". > derby.stream.error.extendedDiagSeverityLevel=30000 > means turn on TRANSACTION_SEVERITY type of error that the extended > thread dump information for errors of transaction severity or > higher. Suggest: "derby.stream.error.extendedDiagSeverityLevel=30000 means that extra diagnostics and thread dump will be activated for errors with severity equal to og higher than transaction severity (30000)." > Please consult the Derby documentation for explanation of error > severity and for other possible settings of > extenedDiagSeverityLevel. Thanks, Dag
          Hide
          Lily Wei added a comment -

          Thanks Dag for reviewing in such details. I feel I shall help more on DERBY-4741 since you help me so much.
          Some further legibility improvement suggestions:

          > Summary of Change
          >
          > Derby will by default dump as much thread dump and diagnostic
          > information as possible on system crash or session error.
          > i.e. users will find thread dump information with error severity
          > higher than session error in derby.log.

          Possible improvement:

          On experiencing a system crash or session error, Derby will print as
          much diagnostic information as possible to the Derby error log,
          including stack traces of all threads.
          >>I change to reflect the suggestion.

          > It is also possible to get thread dump and diagnostic information of
          > errors with lower severity by adjusting a property.

          This one is good, maybe change "of" to "for",
          >>Thanks. Done!

          > Symptoms Seen by Applications Affected by Change

          > If errors have error severity level greater or equal than value
          > derby.stream.error.extendedDiagSeverityLevel is set, thread dump
          > information and extened diagnostic information will be handle by
          > Derby. Users can find thread dump information in derby.log. For ibm
          > JVM users, a javacore file will be created.

          I still feel this information belongs in the first section, and that
          this section should be N/A. I agree this is useful

          "handle" -> "printed"
          "in derby.log" -> "in the Derby error log"

          ibm -> IBM
          >>I see your point. I still feel it does not hurt to be here for users who only view this section for release note.

          > Incompatibilities with Previous Release
          >
          > None

          > Rationale for Change
          >
          > The intention of the change to get more detail information relate to

          "relate" -> "related"
          >>Done.

          > the status of Derby when user hit system crash or server session
          > error.

          Suggest_

          "the status of Derby when important errors happen, "important" by
          default meaning errors with session severity and higher. This will
          help users, DBAs and support personnel to determine the exact cause of
          the error condition."
          >>I change the release note to reflect to the suggestion.

          > Application Changes Required
          >
          > Users do not need to change anything for this change. If more thread
          > dump information is required for error that have severity level less
          > than session error, derby.stream.error.extendedDiagSeverityLevel can

          "derby.stream.error.extendedDiagSeverityLevel" ->
          "the property derby.stream.error.extendedDiagSeverityLevel"

          > be set in the file "derby.properties" or as part of the JVM
          > argument.

          In stead of specifying "derby.properties" or JVM argument here,
          wouldn't it be better to just state this is a Derby system property
          and give a link to the documentation? System wide properties can also
          be set programmatically. You could also say, here as an example, "for
          example, in derby.properties" but not try to enumerate all ways it can
          be set.

          http://db.apache.org/derby/docs/10.7/devguide/cdevsetprop16827.html

          >>Thank you so much for the link. I was trying find the link and add it to it. The users will see the link in this releaseNote.html.

          > For example, if there is a deadlock issue and users would
          > like to see thread dump information while the deadlock is happening,
          > users can then set
          > derby.stream.error.extendedDiagSeverityLevel=30000 in the file
          > "derby.properties" or as part of JVM argument,
          > e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000.

          See above comment, drop how to to set it here altogether, just show
          the value required.

          > The thread dump information is found in the Derby error log,

          "The thread dump information" ->
          "The diagnostics and the thread dump information"

          > typically this is the file "derby.log".

          > derby.stream.error.extendedDiagSeverityLevel=30000
          > means turn on TRANSACTION_SEVERITY type of error that the extended
          > thread dump information for errors of transaction severity or
          > higher.

          Suggest:

          "derby.stream.error.extendedDiagSeverityLevel=30000 means that extra
          diagnostics and thread dump will be activated for errors with
          severity equal to og higher than transaction severity (30000)."
          >>The change is reflected to the suggestion.

          > Please consult the Derby documentation for explanation of error
          > severity and for other possible settings of
          > extenedDiagSeverityLevel.

          Show
          Lily Wei added a comment - Thanks Dag for reviewing in such details. I feel I shall help more on DERBY-4741 since you help me so much. Some further legibility improvement suggestions: > Summary of Change > > Derby will by default dump as much thread dump and diagnostic > information as possible on system crash or session error. > i.e. users will find thread dump information with error severity > higher than session error in derby.log. Possible improvement: On experiencing a system crash or session error, Derby will print as much diagnostic information as possible to the Derby error log, including stack traces of all threads. >>I change to reflect the suggestion. > It is also possible to get thread dump and diagnostic information of > errors with lower severity by adjusting a property. This one is good, maybe change "of" to "for", >>Thanks. Done! > Symptoms Seen by Applications Affected by Change > If errors have error severity level greater or equal than value > derby.stream.error.extendedDiagSeverityLevel is set, thread dump > information and extened diagnostic information will be handle by > Derby. Users can find thread dump information in derby.log. For ibm > JVM users, a javacore file will be created. I still feel this information belongs in the first section, and that this section should be N/A. I agree this is useful "handle" -> "printed" "in derby.log" -> "in the Derby error log" ibm -> IBM >>I see your point. I still feel it does not hurt to be here for users who only view this section for release note. > Incompatibilities with Previous Release > > None > Rationale for Change > > The intention of the change to get more detail information relate to "relate" -> "related" >>Done. > the status of Derby when user hit system crash or server session > error. Suggest_ "the status of Derby when important errors happen, "important" by default meaning errors with session severity and higher. This will help users, DBAs and support personnel to determine the exact cause of the error condition." >>I change the release note to reflect to the suggestion. > Application Changes Required > > Users do not need to change anything for this change. If more thread > dump information is required for error that have severity level less > than session error, derby.stream.error.extendedDiagSeverityLevel can "derby.stream.error.extendedDiagSeverityLevel" -> "the property derby.stream.error.extendedDiagSeverityLevel" > be set in the file "derby.properties" or as part of the JVM > argument. In stead of specifying "derby.properties" or JVM argument here, wouldn't it be better to just state this is a Derby system property and give a link to the documentation? System wide properties can also be set programmatically. You could also say, here as an example, "for example, in derby.properties" but not try to enumerate all ways it can be set. http://db.apache.org/derby/docs/10.7/devguide/cdevsetprop16827.html >>Thank you so much for the link. I was trying find the link and add it to it. The users will see the link in this releaseNote.html. > For example, if there is a deadlock issue and users would > like to see thread dump information while the deadlock is happening, > users can then set > derby.stream.error.extendedDiagSeverityLevel=30000 in the file > "derby.properties" or as part of JVM argument, > e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000. See above comment, drop how to to set it here altogether, just show the value required. > The thread dump information is found in the Derby error log, "The thread dump information" -> "The diagnostics and the thread dump information" > typically this is the file "derby.log". > derby.stream.error.extendedDiagSeverityLevel=30000 > means turn on TRANSACTION_SEVERITY type of error that the extended > thread dump information for errors of transaction severity or > higher. Suggest: "derby.stream.error.extendedDiagSeverityLevel=30000 means that extra diagnostics and thread dump will be activated for errors with severity equal to og higher than transaction severity (30000)." >>The change is reflected to the suggestion. > Please consult the Derby documentation for explanation of error > severity and for other possible settings of > extenedDiagSeverityLevel.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching an updated release note.

          Made the summary a one-liner ("Improved error diagnostics on system crashes and session errors") so that it fits nicely into the short list of changes. The extra information contained in the original summary was incorporated into the other sections.

          Show
          Knut Anders Hatlen added a comment - Attaching an updated release note. Made the summary a one-liner ("Improved error diagnostics on system crashes and session errors") so that it fits nicely into the short list of changes. The extra information contained in the original summary was incorporated into the other sections.
          Hide
          Rick Hillegas added a comment -

          Adjust the release note.

          Show
          Rick Hillegas added a comment - Adjust the release note.

            People

            • Assignee:
              Lily Wei
              Reporter:
              Lily Wei
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development