[
https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582552#action_12582552
]
Øystein Grøvlen commented on DERBY-3526:
----------------------------------------
Code looks good. My only suggestion is that for the following code:
synchronized(objLSTSync) {
shippingInterval = calculateSIfromFI();
if (shippingInterval != -1) {
objLSTSync.wait(shippingInterval);
}
}
the synchronization should be done within the if-block.
shippingInterval does not seem to be accessed by other threads, so it
does not need to be protected by synchronization.
> AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log
> chunk
> ----------------------------------------------------------------------------------
>
> Key: DERBY-3526
> URL: https://issues.apache.org/jira/browse/DERBY-3526
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.0.0, 10.5.0.0
> Reporter: Jørgen Løland
> Assignee: V.Narayanan
> Attachments: Derby3526.diff, Derby3526.stat
>
>
> The replication log shipper thread synchronizes on 'this' both when shipping
> log records (shipALogChunk) and when it waits between log shipments.
> Transaction threads may try to wake up the log shipper because log has
> arrived that should be shipped (i.e., through the method workToDo). These
> threads should not have to wait for the monitor if the log shipper is
> currently busy shipping log. The solution is to have two monitors - one for
> log shipment and one for waiting between log shipment.
> This may seem like a minor issue, but if the TCP connection between master
> and slave is lost e.g. because a network cable has been unplugged, the log
> shipper will block for 2 minutes on ObjectOutputStream#writeObject.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
