db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3618) Perform thread dump with ASSERTS with jdk 1.5 or higher
Date Fri, 16 May 2008 18:35:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597571#action_12597571

Bryan Pendleton commented on DERBY-3618:

> don't have a suggestion for automated testing to check the derby.log

I'm just blue-sky thinking here, but here are some possible ideas:

1) Write some common shared utility code that uses java.io.* classes to
go find the derby.log file on disk and read it.

2) Inject some sort of "duplicate" or "tee" stream into the output routines
that write to derby.log so that they can be hooked to emit output *both*
to derby.log and to some other stream (say, an in-memory byte-array
stream) that can then be examined for the content in question.

3) Change the output routines that write to derby.log so that they have
some sort of "registered handler" concept so that, immediately prior
to writing some data to derby.log, they call back to any registered output
handlers to give the handler a chance to examine the data that's about
to be written.

One way to look at these options is whether the test hooks should examine
the derby.log output after-the-fact, as-the-data-is-being-written, or

Another way is whether the right abstraction layer is to consider the
file as a whole as a stream of data, or each individual "record" as it
is being written to the file.

And yet another way to look at the options is whether it's easiest to write
the test code as callback handlers, or as stream-content verifiers. How
will it be easiest to recognize the logging content that you're looking for?

Solutions (2) and (3) assume that the test code is in the same JVM as
the Derby code being tested, so they wouldn't work so well for network
server tests, although for this particular case that might be just fine.

Just thought I'd try to throw some ideas out there to encourage the discussion.

> Perform thread dump with ASSERTS with jdk 1.5 or higher
> -------------------------------------------------------
>                 Key: DERBY-3618
>                 URL: https://issues.apache.org/jira/browse/DERBY-3618
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:
>            Reporter: Kathey Marsden
>            Assignee: Erlend Birkenes
>            Priority: Minor
> It would be good to have a stack traces for all threads dump to the derby.log when an
assertion occurs with JVM's that support it.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message