[
https://issues.apache.org/jira/browse/DERBY-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001037#comment-13001037
]
Kristian Waagan commented on DERBY-5051:
----------------------------------------
Hi Kim,
That last line is the new index statistics update daemon printing its
statistics on shutdown. It is cryptic and noone - myself being an exception I
hope - will understand it...
I wrote this code, but since I'm on leave right now the logging code hasn't
been worked on as much as it should have. I think the line is important for
early stage investigation/observation in the wild, but agree that is may cause
confusion.
Some improvements:
a) Print it only if the daemon has actually done something.
b) Document why the line is printed, i.e. for debugging/observability, and
how it can be disabled (see below). Do we already have something written down
for the new feature?
c) Document the meaning of the various metrics.
To give people a chance to judge the usefulness of this line, I'll briefly
explain the metrics printed:
- active : whether the worker thread was running when the daemon was shut down
(in code: runningThread != null)
- work : ms spent doing work
- age : ms since daemon creation
- q : work units currently queued
- p : work units processed
- s : work units scheduled
- k : number of known/excpected errors encountered (i.e table is dropped while
being scanned)
- u : number of unexpected errors encountered (these will affect the current
work unit, but the daemon will remain active)
- c : number of consecutive errors encountered (daemon will be disabled if a
threshold is exceeded)
- f : rejections due to a full queue
- d : rejections due to work unit duplicates
- o : rejections due to other causes, which is currently only attempts to
schedule a work unit after the daemon has been disabled
Currently logging for the istat feature will be enabled by default, unless it
has been specifically disabled by setting derby.storage.indexStats.log=false
> Update the docs to include the additional information available in derby.log.
> This information will be useful from product supportability stand point
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5051
> URL: https://issues.apache.org/jira/browse/DERBY-5051
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.8.0.0
> Reporter: Mamta A. Satoor
> Assignee: Kim Haase
>
> With DERBY-4853, we log additional information in derby.log to make it easier
> for the support group to work with customer problems.
> Following 2 additional properties will now always be put in derby.log (every
> time a database is booted)
> user.dir
> derby.system.home
> user.dir is the system property which gives the user working directory.
> If the user has not specified derby,system.home, then Derby will look for
> optional derby.properties file in user.dir . If user has provided
> derby.system.home, then the optional derby.properties will be looked in
> derby.system.home rather than user.dir
> If user has not provided derby.system.home, then a sample of the 2 properties
> on derby.log looks as follows on my machine
> user.dir=C:\p4clients\svnmain\client2\trunk\systest\out142
> derby.system.home=null
> If user has set derby.system.home to c:./temp, then a sample of the 2
> properties on derby.log looks as follows on my machine
> user.dir=C:\p4clients\svnmain\client2\trunk\systest\out142
> derby.system.home=c:/temp
> In addition to the above 2 properties, there can be following 3 optional
> properties in the log (following the 2 properties mentioned above)
> derby.stream.error.file
> derby.stream.error.method
> derby.stream.error.field
> The above 3 properties provide a way to alter where error messages get logged
> rather than tranditional derby.log file. In the absence of the above 3
> optional properties, the location of derby.log follows the same logic as
> derby.properties. But if the user has set any or all of the 3 optional
> properties, then derby.log will not be in same location as derby.properties.
> In the Derby code, derby.stream.error.file takes precedence over the other 2
> properties and derby.stream.error.method take precedence over the last
> property.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira