[jira] Updated: (DERBY-3567) AsynchronousLogShipper#forceFlush should time out

["Øystein Grøvlen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Øystein Grøvlen updated DERBY-3567:
-----------------------------------

    Attachment: derby-3567-1b.diff

I discovered that my scenario with multiple waiting threads are not possible since calls to appendLog is protected by logFileSemaphore in LogAccessFile.  Hence, it is not strictly necessary to make forceFlush thread safe.  However, I think my suggestion simplifies the code, and I do not the extra overhead of calling notify on each send instead of checking a volatile field should be very large. Patch derby-3567-1b.diff removes the volatile variable.

> 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.