You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Eric Dong (JIRA)" <ji...@apache.org> on 2012/08/01 20:52:03 UTC
[jira] [Created] (CASSANDRA-4479) Multiple phi_convict_threshold
fields not all settable via JMX
Eric Dong created CASSANDRA-4479:
------------------------------------
Summary: 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
[jira] [Updated] (CASSANDRA-4479) JMX attribute setters not
consistent with cassandra.yaml
Posted by "Chris Merrill (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Merrill updated CASSANDRA-4479:
-------------------------------------
Attachment: trunk-4479.txt
> JMX attribute setters not consistent with cassandra.yaml
> --------------------------------------------------------
>
> 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
> Attachments: trunk-4479.txt
>
>
> If a setting is configurable both via cassandra.yaml and JMX, the two should be consistent. If that doesn't hold, then the JMX setter can't be trusted.
> Here I present the example of 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.
> So, I'm requesting the following:
> * Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
> * Going through the list of configuration parameters and fixing any that don't match those guidelines
> I'd also recommend logging any changes to configuration parameters.
--
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
[jira] [Updated] (CASSANDRA-4479) JMX attribute setters not
consistent with cassandra.yaml
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-4479:
--------------------------------------
Reviewer: brandon.williams
Priority: Trivial (was: Major)
Affects Version/s: (was: 1.1.2)
Fix Version/s: 1.2.0
> JMX attribute setters not consistent with cassandra.yaml
> --------------------------------------------------------
>
> Key: CASSANDRA-4479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4479
> Project: Cassandra
> Issue Type: Bug
> Reporter: Eric Dong
> Priority: Trivial
> Fix For: 1.2.0
>
> Attachments: trunk-4479.txt
>
>
> If a setting is configurable both via cassandra.yaml and JMX, the two should be consistent. If that doesn't hold, then the JMX setter can't be trusted.
> Here I present the example of 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.
> So, I'm requesting the following:
> * Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
> * Going through the list of configuration parameters and fixing any that don't match those guidelines
> I'd also recommend logging any changes to configuration parameters.
--
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
[jira] [Commented] (CASSANDRA-4479) JMX attribute setters not
consistent with cassandra.yaml
Posted by "Eric Dong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427012#comment-13427012 ]
Eric Dong commented on CASSANDRA-4479:
--------------------------------------
A quick-and-dirty laundry list of MBean setters:
{noformat}
$ find . -name '*MBean.java' -exec grep 'void set' {} +
./src/java/org/apache/cassandra/concurrent/JMXConfigurableThreadPoolExecutorMBean.java: void setCorePoolSize(int n);
./src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java: public void setMinimumCompactionThreshold(int threshold);
./src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java: public void setMaximumCompactionThreshold(int threshold);
./src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java: public void setCompactionStrategyClass(String className) throws ConfigurationException;
./src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java: public void setCompressionParameters(Map<String,String> opts) throws ConfigurationException;
./src/java/org/apache/cassandra/gms/FailureDetectorMBean.java: public void setPhiConvictThreshold(int phi);
./src/java/org/apache/cassandra/service/CacheServiceMBean.java: public void setRowCacheSavePeriodInSeconds(int rcspis);
./src/java/org/apache/cassandra/service/CacheServiceMBean.java: public void setKeyCacheSavePeriodInSeconds(int kcspis);
./src/java/org/apache/cassandra/service/CacheServiceMBean.java: public void setRowCacheCapacityInMB(long capacity);
./src/java/org/apache/cassandra/service/CacheServiceMBean.java: public void setKeyCacheCapacityInMB(long capacity);
./src/java/org/apache/cassandra/service/StorageProxyMBean.java: public void setHintedHandoffEnabled(boolean b);
./src/java/org/apache/cassandra/service/StorageProxyMBean.java: public void setMaxHintWindow(int ms);
./src/java/org/apache/cassandra/service/StorageProxyMBean.java: public void setMaxHintsInProgress(int qs);
./src/java/org/apache/cassandra/service/StorageProxyMBean.java: public void setRpcTimeout(Long timeoutInMillis);
./src/java/org/apache/cassandra/service/StorageServiceMBean.java: public void setLog4jLevel(String classQualifier, String level);
./src/java/org/apache/cassandra/service/StorageServiceMBean.java: public void setStreamThroughputMbPerSec(int value);
./src/java/org/apache/cassandra/service/StorageServiceMBean.java: public void setCompactionThroughputMbPerSec(int value);
./src/java/org/apache/cassandra/service/StorageServiceMBean.java: public void setIncrementalBackupsEnabled(boolean value);
{noformat}
DatabaseDescriptor setters; according to [ArchitectureInternals|http://wiki.apache.org/cassandra/ArchitectureInternals], all node configuration parameters should be in here:
{noformat}
$ grep 'void set' src/java/org/apache/cassandra/config/DatabaseDescriptor.java
public static void setPartitioner(IPartitioner newPartitioner)
public static void setEndpointSnitch(IEndpointSnitch eps)
public static void setRpcTimeout(Long timeOutInMillis)
public static void setInMemoryCompactionLimit(int sizeInMB)
public static void setCompactionThroughputMbPerSec(int value)
public static void setStreamThroughputOutboundMegabitsPerSec(int value)
public static void setBroadcastAddress(InetAddress broadcastAdd)
public static void setDynamicUpdateInterval(Integer dynamicUpdateInterval)
public static void setDynamicResetInterval(Integer dynamicResetInterval)
public static void setDynamicBadnessThreshold(Double dynamicBadnessThreshold)
public static void setIncrementalBackupsEnabled(boolean value)
{noformat}
> JMX attribute setters not consistent with cassandra.yaml
> --------------------------------------------------------
>
> 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. If that doesn't hold, then the JMX setter can't be trusted.
> Here I present the example of 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.
> So, I'm requesting the following:
> * Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
> * Going through the list of configuration parameters and fixing any that don't match those guidelines
> I'd also recommend logging any changes to configuration parameters.
--
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
[jira] [Commented] (CASSANDRA-4479) JMX attribute setters not
consistent with cassandra.yaml
Posted by "Chris Merrill (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428387#comment-13428387 ]
Chris Merrill commented on CASSANDRA-4479:
------------------------------------------
I'm looking into this and will submit a patch for consideration.
> JMX attribute setters not consistent with cassandra.yaml
> --------------------------------------------------------
>
> 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. If that doesn't hold, then the JMX setter can't be trusted.
> Here I present the example of 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.
> So, I'm requesting the following:
> * Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
> * Going through the list of configuration parameters and fixing any that don't match those guidelines
> I'd also recommend logging any changes to configuration parameters.
--
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
[jira] [Commented] (CASSANDRA-4479) Multiple phi_convict_threshold
fields not all settable via JMX
Posted by "Eric Dong (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (CASSANDRA-4479) JMX attribute setters not
consistent with cassandra.yaml
Posted by "Eric Dong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Dong updated CASSANDRA-4479:
---------------------------------
Description:
If a setting is configurable both via cassandra.yaml and JMX, the two should be consistent. If that doesn't hold, then the JMX setter can't be trusted.
Here I present the example of 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.
So, I'm requesting the following:
* Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
* Going through the list of configuration parameters and fixing any that don't match those guidelines
I'd also recommend logging any changes to configuration parameters.
was:
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.
Summary: JMX attribute setters not consistent with cassandra.yaml (was: Multiple phi_convict_threshold fields not all settable via JMX)
> JMX attribute setters not consistent with cassandra.yaml
> --------------------------------------------------------
>
> 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. If that doesn't hold, then the JMX setter can't be trusted.
> Here I present the example of 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.
> So, I'm requesting the following:
> * Setting up guidelines for how to expose a configuration parameter both via cassandra.yaml and JMX, based on what I've mentioned above
> * Going through the list of configuration parameters and fixing any that don't match those guidelines
> I'd also recommend logging any changes to configuration parameters.
--
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