Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <740376622.1207136544733.JavaMail.jira@brutus>
Date: Wed, 2 Apr 2008 04:42:24 -0700 (PDT)
From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3567) AsynchronousLogShipper#forceFlush
 should time out
In-Reply-To: <212856340.1206436644948.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3567?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1258=
4520#action_12584520 ]=20

=C3=98ystein Gr=C3=B8vlen commented on DERBY-3567:
----------------------------------------

Thanks for the patch, J=C3=B8rgen. =20
If I am not wrong, I think that with this patch there is a chance that thre=
ads that are waiting for a flush, will not be notified.
Consider the case when two threads are calling forceFlush concurrently.  As=
 far as I can tell, both may be waiting for a log send to complete, but onl=
y one thread will be notified when the sending has been completed.  Since, =
forceFlushed is then false, no further notification may be done.  Hence, th=
e second thread may time out and cause replication to be stopped.

I do not think it will work to just switch to notifyAll, since it is not gu=
aranteed that a single write is sufficient to have space for all waiting th=
reads to write their log records.  Instead, I suggest that notify can be ca=
lled after every send, regardless of whether anyone may be waiting or not. =
 I am not sure the extra synchronization overhead will be big since the cur=
rent solution involves access to a volatile variable anyway.


> 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=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>         Attachments: derby-3567-1a.diff, derby-3567-1a.stat
>
>
> If the network connection to the slave is lost, ObjectOutputStream#writeO=
bject may be blocked for 2 minutes before failing (not configurable TCP pro=
perty).=20
> Currently, ALS#forceFlush sends a chunk of log to the slave using the cli=
ent 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 immed=
iately, and then wait for a short while (until notified or e.g. maximum 5 s=
econds). If the log shipper has not been able to empty some space in the lo=
g buffer by then, replication should be stopped.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.