cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426824#comment-13426824
] 

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: https://issues.apache.org/jira/browse/CASSANDRA-4479
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message