[
https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lily Wei updated DERBY-4856:
----------------------------
Attachment: releaseNote.html
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.
> Add thread dump information when derby crash
> --------------------------------------------
>
> Key: DERBY-4856
> URL: https://issues.apache.org/jira/browse/DERBY-4856
> Project: Derby
> Issue Type: Bug
> Components: Services
> Reporter: Lily Wei
> Assignee: Lily Wei
> Priority: Minor
> Fix For: 10.8.0.0
>
> Attachments: ContextManager.java, corruptdb.zip, derby-4856-1a.diff,
> DERBY-4856-part_1_1a.diff, DERBY-4856_part_2_2a.diff,
> DERBY-4856_part_2_2b.diff, DERBY-4856_part_3_1a.diff,
> DERBY-4856_part_3_2a.diff, DERBY-4856_part_3_3a.diff,
> DERBY-4856_part_3_3b.diff, DERBY-4856_part_3_3c.diff,
> DERBY-4856_part_3_3d.diff, DERBY-4856_part_3_3e.diff,
> DERBY-4856_part_3_3g.diff, DERBY-4856_part_3_3g_1a.diff,
> DERBY-4856_part_3_3g_2a.diff, derby.log, releaseNote.html, releaseNote.html,
> releaseNote.html
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
