Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 27 Jan 2016 10:27:39 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12934027.1453779329000.222995.1453890459939@Atlassian.JIRA>
In-Reply-To: <JIRA.12934027.1453779329000@Atlassian.JIRA>
References: <JIRA.12934027.1453779329000@Atlassian.JIRA>
 <JIRA.12934027.1453779329695@arcas>
Subject: [jira] [Commented] (CASSANDRA-11070) Dispatcher.Flusher's control
 has duplicated/conflict control
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-11070?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15118992#comment-15118992 ]=20

Benedict commented on CASSANDRA-11070:
--------------------------------------

It is not >10us vs >20us; it is n ~>=3D 10us, and choosing between n and 2n=
; on some systems under high load n could be significantly greater than 10u=
s, perhaps 100us, perhaps 1ms; making it twice n is potentially worse than =
just adding 10us.

In general, this code is pretty critical to the behaviour of the system.  T=
he current behaviour was chosen somewhat arbitrarily by me, but it has been=
 fairly thoroughly tested.  With sufficient testing a different arbitrary b=
ehaviour would be fine.

I would personally tend towards simply always flushing either on the second=
 run, if we were to aim for simplicity; possibly with a zero delay (so that=
 it just runs at the end of a natural batch), as this is less work, more re=
sponsive, and in all likelihood the main benefit is from batching the natur=
al groupings of messages.

I also, however, don't think this guard is a meaningful contributor to comp=
lexity in the codebase, and that we've already spent more time discussing t=
he _guard_ than it deserves.  However, analysis of the client batching and =
improvements to it are central to system behaviour, so further research is =
obviously welcomed.  Since this ticket is discussing duplicated behaviour w=
hich is demonstrably absent, I'm closing as Won't Fix.

> Dispatcher.Flusher's control has duplicated/conflict control
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-11070
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1107=
0
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Streaming and Messaging
>            Reporter: fujian
>              Labels: performance
>         Attachments: 0001-fix-CASSANDRA-11070.patch
>
>
> org.apache.cassandra.transport.Message.Dispatcher.Flusher
> remove duplicated control for flush message control =E2=80=A6
> Motivation:
> the !doneWork's control is duplicated and confused with runsSinceFlush > =
2
> if on the first run:the queue size is 20
> donework will be set to true and not do flush due to the size<50 and runs=
SinceFlush<2.
> if on the second run. the queue size is 0,
> donework will be reset to false and not set to true due to no new items i=
n queue, but the flush will be triggered due to:
>   if (!doneWork || runsSinceFlush > 2 || flushed.size() > 50)
> now the runsSinceFlush is 2. so in actual, its function is similar with r=
unsSinceFlush>1.
> so it is no need to keep it so that the code is confused and duplicated.
>              =20
> Modifications:
> remove it
> Result:
> after remove it, it will more clear and no confused.
> =20


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)