[
https://issues.apache.org/jira/browse/CASSANDRA-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118992#comment-15118992
]
Benedict commented on CASSANDRA-11070:
--------------------------------------
It is not >10us vs >20us; it is n ~>= 10us, and choosing between n and 2n; on
some systems under high load n could be significantly greater than 10us,
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. The
current behaviour was chosen somewhat arbitrarily by me, but it has been fairly
thoroughly tested. With sufficient testing a different arbitrary behaviour
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
responsive, and in all likelihood the main benefit is from batching the natural
groupings of messages.
I also, however, don't think this guard is a meaningful contributor to
complexity in the codebase, and that we've already spent more time discussing
the _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 which
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-11070
> 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 …
> 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
> runsSinceFlush<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 in
> 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
> runsSinceFlush>1.
> so it is no need to keep it so that the code is confused and duplicated.
>
> Modifications:
> remove it
> Result:
> after remove it, it will more clear and no confused.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
