[
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-1b.diff
derby-3388-tstamp-and-properties-1b.stat
Thanks for reviewing the patch, Knut. Patch v1b addresses your comments:
1: yes - will be documented
2: changed to getSystemBoolean, but have to check if the property is set first
because I want it to default to true.
3: I now create a ReplicationLogger object instead of using static logging
methods. That will ensure that the check is performed at the time replication
is started
4, 5: agree. done
6: good point. I'll address this in a followup patch
All tests except the ones who fail in tinderbox (predicatePushdown.sql,
TransactionTable.sql) passed.
> 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.
