You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "J.B. Langston (JIRA)" <ji...@apache.org> on 2012/08/22 21:30:43 UTC
[jira] [Updated] (CASSANDRA-4568) countPendingHints JMX operation
is returning garbage for the key
[ https://issues.apache.org/jira/browse/CASSANDRA-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
J.B. Langston updated CASSANDRA-4568:
-------------------------------------
Description:
countPendingHints JMX operation should return a map from key: endpoint IP address to value: number of pending hints. It is returning garbage for the key (looks like binary data concerning the hint itself). The value looks correct.
Steps to reproduce:
1) Set up a two-node cluster.
2) Disable gossip on the second node.
`nodetool ring` output from node 1:
Address DC Rack Status State Load Effective-Ownership Token
85070591730234615865843651857942052864
192.168.1.162 datacenter1 rack1 Up Normal 21.46 KB 100.00% 0
192.168.1.130 datacenter1 rack1 Down Normal 6.67 KB 100.00% 85070591730234615865843651857942052864
3) While the second node is still down, create a keyspace with RF=2 and a CF within this keyspace. Then insert two records into the CF:
Connected to Test Cluster at 192.168.1.162:9160.
[cqlsh 2.2.0 | Cassandra 1.1.2 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Use HELP for help.
cqlsh> create KEYSPACE demo WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor = 2;
cqlsh> use demo;
cqlsh:demo> create table users (username varchar primary key, password varchar);
cqlsh:demo> insert into users (username, password) values (scott, tiger);
cqlsh:demo> insert into users (username, password) values (root, password);
4) Use a JMX client to execute the countPendingHints operation:
jblangston:~ jblangston$ java -jar cmdline-jmxclient-0.10.3.jar - localhost:7199 org.apache.cassandra.db:type=HintedHandoffManager countPendingHints
08/22/2012 14:21:37 -0500 org.archive.jmx.Client countPendingHints: {@B^h ?? ?[b??scottdemoscott?????password?ߞHtigerdemoF
?P?? ?[b??rootdemoroot?????password?ߞ?Wpassworddemo=2}
5) Notice the output. The value (2) is correct but the key is garbage instead of an endpoint IP address.
was:
countPendingHints JMX operation should return a map from key: endpoint IP address to value: number of pending hints. It is returning garbage for the key (looks like binary data concerning the hint itself). The value looks correct.
Steps to reproduce:
1) Set up a two-node cluster. Disable gossip on the second node.
`nodetool ring` output from node 1:
Address DC Rack Status State Load Effective-Ownership Token
85070591730234615865843651857942052864
192.168.1.162 datacenter1 rack1 Up Normal 21.46 KB 100.00% 0
192.168.1.130 datacenter1 rack1 Down Normal 6.67 KB 100.00% 85070591730234615865843651857942052864
2) While the second node is still down, create a keyspace with RF=2 and a CF within this keyspace. Then insert two records into the CF:
Connected to Test Cluster at 192.168.1.162:9160.
[cqlsh 2.2.0 | Cassandra 1.1.2 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
Use HELP for help.
cqlsh> create KEYSPACE demo WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor = 2;
cqlsh> use demo;
cqlsh:demo> create table users (username varchar primary key, password varchar);
cqlsh:demo> insert into users (username, password) values (scott, tiger);
cqlsh:demo> insert into users (username, password) values (root, password);
3) Use a JMX client to execute the countPendingHints operation:
jblangston:~ jblangston$ java -jar cmdline-jmxclient-0.10.3.jar - localhost:7199 org.apache.cassandra.db:type=HintedHandoffManager countPendingHints
08/22/2012 14:21:37 -0500 org.archive.jmx.Client countPendingHints: {@B^h ?? ?[b??scottdemoscott?????password?ߞHtigerdemoF
?P?? ?[b??rootdemoroot?????password?ߞ?Wpassworddemo=2}
4) Notice output. The value (2) is correct but the key is garbage instead of an endpoint IP address.
> countPendingHints JMX operation is returning garbage for the key
> ----------------------------------------------------------------
>
> Key: CASSANDRA-4568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4568
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.10, 1.1.2
> Reporter: J.B. Langston
> Priority: Minor
>
> countPendingHints JMX operation should return a map from key: endpoint IP address to value: number of pending hints. It is returning garbage for the key (looks like binary data concerning the hint itself). The value looks correct.
> Steps to reproduce:
> 1) Set up a two-node cluster.
> 2) Disable gossip on the second node.
> `nodetool ring` output from node 1:
> Address DC Rack Status State Load Effective-Ownership Token
> 85070591730234615865843651857942052864
> 192.168.1.162 datacenter1 rack1 Up Normal 21.46 KB 100.00% 0
> 192.168.1.130 datacenter1 rack1 Down Normal 6.67 KB 100.00% 85070591730234615865843651857942052864
> 3) While the second node is still down, create a keyspace with RF=2 and a CF within this keyspace. Then insert two records into the CF:
> Connected to Test Cluster at 192.168.1.162:9160.
> [cqlsh 2.2.0 | Cassandra 1.1.2 | CQL spec 2.0.0 | Thrift protocol 19.32.0]
> Use HELP for help.
> cqlsh> create KEYSPACE demo WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor = 2;
> cqlsh> use demo;
> cqlsh:demo> create table users (username varchar primary key, password varchar);
> cqlsh:demo> insert into users (username, password) values (scott, tiger);
> cqlsh:demo> insert into users (username, password) values (root, password);
> 4) Use a JMX client to execute the countPendingHints operation:
> jblangston:~ jblangston$ java -jar cmdline-jmxclient-0.10.3.jar - localhost:7199 org.apache.cassandra.db:type=HintedHandoffManager countPendingHints
> 08/22/2012 14:21:37 -0500 org.archive.jmx.Client countPendingHints: {@B^h ?? ?[b??scottdemoscott?????password?ߞHtigerdemoF
> ?P?? ?[b??rootdemoroot?????password?ߞ?Wpassworddemo=2}
> 5) Notice the output. The value (2) is correct but the key is garbage instead of an endpoint IP address.
--
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