[
https://issues.apache.org/jira/browse/CASSANDRA-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721705#comment-15721705
]
Stefan Podkowinski commented on CASSANDRA-12966:
------------------------------------------------
My personally preference for this kind of API design is to provide the executor
as a method parameter. This makes it obvious (while reading the code on the
caller side) to recognize the asynchronous nature of the function, as well as
in what executor context will be used to run the code. In case of the discussed
{{updateTokens}} method, I'd probably just add the {{Stage}} enum as another
parameter, so you'd call {{SystemKeyspace.updateTokens(endpoint,
tokensToUpdateInSystemKeyspace, Stage.MUTATION)}}.
> Gossip thread slows down when using batch commit log
> ----------------------------------------------------
>
> Key: CASSANDRA-12966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12966
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jason Brown
> Assignee: Jason Brown
> Priority: Minor
>
> When using batch commit log mode, the Gossip thread slows down when peers
> after a node bounces. This is because we perform a bunch of updates to the
> peers table via {{SystemKeyspace.updatePeerInfo}}, which is a synchronized
> method. How quickly each one of those individual updates takes depends on how
> busy the system is at the time wrt write traffic. If the system is largely
> quiescent, each update will be relatively quick (just waiting for the fsync).
> If the system is getting a lot of writes, and depending on the
> commitlog_sync_batch_window_in_ms, each of the Gossip thread's updates can
> get stuck in the backlog, which causes the Gossip thread to stop processing.
> We have observed in large clusters that a rolling restart causes triggers and
> exacerbates this behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
