[
https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584612#action_12584612
]
Jørgen Løland commented on DERBY-3567:
--------------------------------------
> I discovered that my scenario with multiple waiting threads are not possible
> since calls to appendLog is protected by logFileSemaphore in LogAccessFile.
The patch was written under the assumption that only one thread will access
appendLog because of this semaphore, but I forgot to document it.
> what happens if network goes down in flushBuffer? The problem reported in
> this JIRA seems to
exist in flushBuffer also. I think we need a thread in that method too.
I agree - this is a similar case.
> AsynchronousLogShipper#forceFlush should time out
> -------------------------------------------------
>
> Key: DERBY-3567
> URL: https://issues.apache.org/jira/browse/DERBY-3567
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.0.0, 10.5.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: derby-3567-1a.diff, derby-3567-1a.stat,
> derby-3567-1b.diff
>
>
> If the network connection to the slave is lost,
> ObjectOutputStream#writeObject may be blocked for 2 minutes before failing
> (not configurable TCP property).
> Currently, ALS#forceFlush sends a chunk of log to the slave using the client
> thread. The client thread cannot be blocked for 2 minutes before giving up.
> Rather, it should notify the log shipper that it has to send log immediately,
> and then wait for a short while (until notified or e.g. maximum 5 seconds).
> If the log shipper has not been able to empty some space in the log buffer by
> then, replication should be stopped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
