db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-3388) Improve message handling for replication messages to derby.log
Date Fri, 22 Feb 2008 11:00:21 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jørgen Løland updated DERBY-3388:
---------------------------------

    Attachment: derby-3388-tstamp-and-properties-1a.stat
                derby-3388-tstamp-and-properties-1a.diff

Patch derby-3388-tstamp-and-properties-1a adds a timestamp to replication messages written
to derby.log. The following replication properties are also made configurable:

derby.replication.verbose -> true/false - replication messages are written to log
derby.replication.logBufferSize -> the size of the replication log buffers
derby.replication.minLogShippingInterval -> the shortest interval between two consecutive
log shipments
derby.replication.maxLogShippingInterval  -> the longest interval between two consecutive
log shipments (a "soft" guarantee that the slave will not deviate more than this amount of
millis from the master)

All tests passed. The patch is ready for review.

> 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
>
>
> 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