[ https://issues.apache.org/jira/browse/CASSANDRA-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams resolved CASSANDRA-3802. ----------------------------------------- Resolution: Not A Problem UE will be thrown on timeout until 1.1. Increasing rpc_timeout will increase the time until the exception is thrown (but truncate may work despite the exception, TOE always means you don't know what happened) > Cli returns UE on truncate when command is successful > ----------------------------------------------------- > > Key: CASSANDRA-3802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3802 > Project: Cassandra > Issue Type: Bug > Reporter: Joaquin Casares > > Much like: https://issues.apache.org/jira/browse/CASSANDRA-3651 > The UE is returned instead of a timeout error, but in this case, the timeout > error is returned even though the command executes successfully. Could we > have a tunable parameter to increase the timeout period? > Example stacktrace: > {noformat} > [default@cfs] truncate cleanup; > null > UnavailableException() > at > org.apache.cassandra.thrift.Cassandra$truncate_result.read(Cassandra.java:20210) > > at > org.apache.cassandra.thrift.Cassandra$Client.recv_truncate(Cassandra.java:1077) > > at org.apache.cassandra.thrift.Cassandra$Client.truncate(Cassandra.java:1052) > at org.apache.cassandra.cli.CliClient.executeTruncate(CliClient.java:1498) > at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:270) > at > org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220) > > at org.apache.cassandra.cli.CliMain.main(CliMain.java:346) > {noformat} > JNA confirmed on all machines via jinfo. Flush and snapshot confirmed to be > successful individually. > A truncate was tried again and the view from cfstats changed: > {noformat} > Column Family: sblocks > SSTable count: 3 > Space used (live): 22200 > Space used (total): 22200 > Number of Keys (estimate): 384 > Memtable Columns Count: 0 > Memtable Data Size: 0 > Memtable Switch Count: 0 > Read Count: 0 > Read Latency: NaN ms. > Write Count: 0 > Write Latency: NaN ms. > Pending Tasks: 0 > Bloom Filter False Postives: 0 > Bloom Filter False Ratio: 0.00000 > Bloom Filter Space Used: 56 > Key cache capacity: 1000000 > Key cache size: 0 > Key cache hit rate: NaN > Row cache: disabled > Compacted row minimum size: 73 > Compacted row maximum size: 4768 > Compacted row mean size: 1379 > to > Column Family: sblocks > SSTable count: 0 > Space used (live): 0 > Space used (total): 0 > Number of Keys (estimate): 0 > Memtable Columns Count: 0 > Memtable Data Size: 0 > Memtable Switch Count: 0 > Read Count: 0 > Read Latency: NaN ms. > Write Count: 0 > Write Latency: NaN ms. > Pending Tasks: 0 > Bloom Filter False Postives: 0 > Bloom Filter False Ratio: 0.00000 > Bloom Filter Space Used: 0 > Key cache capacity: 1000000 > Key cache size: 0 > Key cache hit rate: NaN > Row cache: disabled > Compacted row minimum size: 0 > Compacted row maximum size: 0 > Compacted row mean size: 0 > {noformat} > even though the UE was still thrown (as a possible TE). > After trying to truncate different cfs back-to-back, one completed > successfully and the rest all followed with successful completions. -- 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