cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Dong (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4479) Multiple phi_convict_threshold fields not all settable via JMX
Date Wed, 01 Aug 2012 19:04:04 GMT


Eric Dong commented on CASSANDRA-4479:

For comparison, rpc_timeout_in_ms is settable through JMX via StorageProxy[MBean], but StorageProxy
doesn't have its own rpc_timeout_in_ms field, it calls DatabaseDescriptor.setRpcTimeout(Long),
which sets Conf.rpc_timeout_in_ms. However, Conf.rpc_timeout_in_ms is neither volatile nor
set via a synchronized method, which is still bad.
> Multiple phi_convict_threshold fields not all settable via JMX
> --------------------------------------------------------------
>                 Key: CASSANDRA-4479
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.1.2
>            Reporter: Eric Dong
> If a setting is configurable both via cassandra.yaml and JMX, the two should be consistent,
but that is not the case for phi_convict_threshold.
> I'm trying to set phi_convict_threshold via JMX, which sets FailureDetector.phiConvictThreshold_,
but this doesn't update Config.phi_convict_threshold, which gets its value from cassandra.yaml
when starting up.
> Some places, such as FailureDetector.interpret(InetAddress), use FailureDetector.phiConvictThreshold_;
others, such as AntiEntropyService.line 813 in cassandra-1.1.2, use Config.phi_convict_threshold:
> {code}
>             // We want a higher confidence in the failure detection than usual because
failing a repair wrongly has a high cost.
>             if (phi < 2 * DatabaseDescriptor.getPhiConvictThreshold())
>                 return;
> {code}
> where DatabaseDescriptor.getPhiConvictThreshold() returns Conf.phi_convict_threshold.
> So, it looks like there are cases where a value is stored in multiple places, and setting
the value via JMX doesn't set all of them. I'd say there should only be a single place where
a configuration parameter is stored, and that single field:
> * should read in the value from cassandra.yaml, optionally falling back to a sane default
> * should be the field that the JMX attribute reads and sets, and
> * any place that needs the current global setting should get it from that field. However,
there could be cases where you read in a global value at the start of a task and keep that
value locally until the end of the task.
> Also, anything settable via JMX should be volatile or set via a synchronized setter,
or else according to the Java memory model other threads may be stuck with the old setting.

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


View raw message