[
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
