Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2146013947.1204801497934.JavaMail.jira@brutus>
Date: Thu, 6 Mar 2008 03:04:57 -0800 (PST)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3388) Improve message handling for
 replication messages to derby.log
In-Reply-To: <24288258.1202208008815.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3388?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1257=
5654#action_12575654 ]=20

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

By the way, I think my question (6) was a bit inaccurate. It seems like the=
 intervals and the buffer size can be persisted in derby.properties (since =
PropertyUtil.getSystemProperty() doesn't only look at system properties, as=
 I though it did). But still, it would make sense to have those properties =
configurable with database granularity instead of system granularity, would=
n't it?

> 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=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>            Priority: Minor
>         Attachments: derby-3388-tstamp-and-properties-1a.diff, derby-3388=
-tstamp-and-properties-1a.stat, derby-3388-tstamp-and-properties-1b.diff, d=
erby-3388-tstamp-and-properties-1b.stat
>
>
> The asynchronous replication functionality writes information to the derb=
y log. It would be good to improve this in the following ways:
> 1: startSlave and stopSlave stack traces are written twice to the log - o=
ne 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=20

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