[
https://issues.apache.org/jira/browse/DERBY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529837
]
Øystein Grøvlen 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 own
> convinience. As i understand it we cannot configure DaemonFactory to transmit
> at our mentioned time interval.
>
> So, When performWork is called entirely depends on how good
> DaemonFactory is feeling :-)
>
> We do not want this to happen, because what if this is too soon for
> us or what if it is too late.
>
> 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.
>
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
> replication 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ørgen Løland
> Assignee: Jørgen Løland
> 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 slave role.
> A replication buffer was added to Derby in DERBY-2926. This issue is for
> modifying the logging subsystem to append log records to this buffer every
> time a log records is appended to the disk buffer (LogAccessFile). This will,
> of course, only be done if it has the master role.
> Currently, I have identified two modifications that will be required in
> LogToFile:
> * LogToFile#appendLogRecord needs to append to the replication buffer after
> 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 taken
> place. The MasterController will decide if any action is required because of
> this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
