Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <26267091.1190633031012.JavaMail.jira@brutus>
Date: Mon, 24 Sep 2007 04:23:51 -0700 (PDT)
From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3051) Replication: Modify logging
 subsystem to append log records to the replication buffer when in
 replication master mode
In-Reply-To: <3507945.1188991845549.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3051?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529837 ]=20

=C3=98ystein Gr=C3=B8vlen commented on DERBY-3051:
----------------------------------------

V.Narayanan (JIRA) wrote:
> I however do not want to do this in the first version of the patch
> for this issue.  I will submit the first version assuming a static
> time interval, keep this issue open and change it in the next
> version if this is OK with the community.

Sounds good to me.  A static, but configurable, timeout interval
should probably be good-enough for most cases.

> The DaemonFactory would call performWork (i.e.) ship log records at its o=
wn
> convinience. As i understand it we cannot configure DaemonFactory to tran=
smit
> at our mentioned time interval.
>=20
> So, When performWork is called entirely depends on how good
> DaemonFactory is feeling :-)
>=20
> We do not want this to happen, because what if this is too soon for
> us or what if it is too late.
>=20
> Hence we introduce a transmit interval variable that calculates the
> difference between the last call and the current call of performWork
> or rather shipALogChunk(forceFlush also)

My concern is that if the Daemon Service have very little else to do,
it will continously call LogShipper#performWork and use a lot of
unecessary CPU for checking the time.

> Sorry about being ambiguous here. ShippingDaemon is Derby's
> DaemonService that is booted up and is not a thread I introduce.
>=20

Using a separate thread would probably give you more flexibility with
respect to how log shipping is scheduled.


> Replication: Modify logging subsystem to append log records to the replic=
ation buffer when in replication master mode
> -------------------------------------------------------------------------=
--------------------------------------------
>
>                 Key: DERBY-3051
>                 URL: https://issues.apache.org/jira/browse/DERBY-3051
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services, Store
>    Affects Versions: 10.4.0.0
>            Reporter: J=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>         Attachments: derby_3051_1.diff, derby_3051_1.stat, derby_3051_1b.=
diff, derby_3051_1b.stat
>
>
> When Derby has the replication master role for a database 'x', it should =
ship all log records generated for this database to the Derby with the slav=
e role. A replication buffer was added to Derby in DERBY-2926. This issue i=
s for modifying the logging subsystem to append log records to this buffer =
every time a log records is appended to the disk buffer (LogAccessFile). Th=
is will, of course, only be done if it has the master role.
> Currently, I have identified two modifications that will be required in L=
ogToFile:
> * LogToFile#appendLogRecord needs to append to the replication buffer aft=
er appending to the disk buffer
> * LogToFile#flush (i.e., the method used to force buffered log records to=
 disk) must notify the Master Controller (DERBY-2977) that a flush has take=
n place. The MasterController will decide if any action is required because=
 of this.=20

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