[
https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578161#action_12578161
]
V.Narayanan commented on DERBY-3526:
------------------------------------
> To use another monitor you will have to use another object to synchronize on.
> Hence instead of:
Ah! Use a different object into whose waiting pool the log shipping thread
will be put in waiting mode.
so calling a notify will release this thread and it will start performing log
shipping.
If the thread is already shipping log the waiting pool will be empty and notify
has
no work. In both cases the workToDo method returns immediately.
So we are basically not using the current object for doing, log shipping and
waiting, and, notifying
the log shipping thread simultaneously.
I guess that is what is meant by
"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. "
Got it < The incandescent lamp inside Narayanan's head starts burning brightly
:-D >
Great! Thanks Oystein and Jorgen :) .
And once more fantastic catch.
> 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
>
> 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.
