db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3388) Improve message handling for replication messages to derby.log
Date Thu, 06 Mar 2008 10:59:00 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575653#action_12575653
] 

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

Thanks Jørgen. I have started the regression tests and intend to commit the patch.

A couple of minor nits that could be addressed in the follow-up patch if you agree:

  - AsynchronousLogShipper.repLogger could be final.

  - Why not make the constant ReplicationLogBuffer.DEFAULT_NUMBER_LOG_BUFFERS public and skip
the getNumberLogBuffers() method?

  - The fields LOG_REPLICATION_MESSAGES and DBNAME in ReplicationLogger aren't static any
more, so I think they should have camel-cased names instead of upper-cased names.

  - ReplicationLogger's constructor could perhaps have a small comment explaining that the
extra complexity is there to ensure that the derby.replication.verbose property defaults to
true. Or perhaps the cleanest way would be to create a new getSystemBoolean() method in PropertyUtil
that takes a default value. I see that other methods like getSystemInt() do this.

> Improve message handling for replication messages to derby.log
> --------------------------------------------------------------
>
>                 Key: DERBY-3388
>                 URL: https://issues.apache.org/jira/browse/DERBY-3388
>             Project: Derby
>          Issue Type: Improvement
>          Components: Replication
>    Affects Versions: 10.4.0.0
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>            Priority: Minor
>         Attachments: derby-3388-tstamp-and-properties-1a.diff, derby-3388-tstamp-and-properties-1a.stat,
derby-3388-tstamp-and-properties-1b.diff, derby-3388-tstamp-and-properties-1b.stat
>
>
> The asynchronous replication functionality writes information to the derby log. It would
be good to improve this in the following ways:
> 1: startSlave and stopSlave stack traces are written twice to the log - one is obviously
enough :)
> 2: It should be possible to configure if replication messages written to the log should
be followed by a stack trace of the cause.
> 3: logged messages should have a timestamp 

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


Mime
View raw message