[
https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3526:
-------------------------------
Attachment: Derby3526.stat
Derby3526.diff
Attached patch that uses a different object to synchronize
on while calling wait and notifying the log shipper thread.
I am not sure on how to add a test to the replication suite to
test this feature (Should failing the slave be a good test for this)
but then again is the complication of the 2 minute wait.
I did not run the replication suite which I hope to in the afternoon.
But I did test starting the slave, master, executing a few transactions,
failing over and it worked fine.
> 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.
