cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5135) calculatePendingRanges could be asynchronous
Date Thu, 10 Jan 2013 02:38:13 GMT


Brandon Williams commented on CASSANDRA-5135:

bq. I think you want a DTPE not a JMXETPE.

Actually I think being able to see the progress via JMX is useful, especially if you're encountering
this problem.

bq. You'll still need to setRejectedExecutionHandler(DiscardPolicy)

Oops, totally missed that.

bq. Do we need to update RING_DELAY to accomodate long cPR times?

RING_DELAY is orthogonal, that is just how long we wait until we're sure we've seen the ring
accurately.  Once divorced from gossip, cPR can theoretically takes as long as it wants, since
a bootstrapping node can just sit there and be a fat client until it's ready.

v2 fixes the handler and the nit.

> calculatePendingRanges could be asynchronous
> --------------------------------------------
>                 Key: CASSANDRA-5135
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Brandon Williams
>            Assignee: Brandon Williams
>             Fix For: 1.1.9
>         Attachments: 5135.txt, 5135-v2.txt
> In the vein of CASSANDRA-3881, cPR is expensive and can end up dominating the gossip
thread, causing all sorts of havoc.  One simple way we can triage this is to simply give it
> s own executor with a queue size of 1 (since we don't actually need to recalculate for
every host we see if we suddenly see many of them) and do the calculation asynchronously,
freeing up the gossiper.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message