U said RF=1...missed that..so not sure eventual consistency is creating issues..
Thanks Anuj Wadehra Sent from Yahoo Mail on Android From:"Anuj Wadehra" <anujw_2...@yahoo.co.in> Date:Sat, 13 Jun, 2015 at 11:31 pm Subject:Re: Dropped mutation messages I think the messages dropped are the asynchronous ones required to maintain eventual consistency. Client may not be complaining as the data gets commited to one node synchronously..but dropped when sent to other nodes asynchronously.. We resolved similar issue in our cluster by increasing memtable_flush_writers to 3 from 1 ( we were writing to multiple cf simultaneously). We also fixed GC issues and reduced total_memtable_size_in_mb to ensure that most memtables are flushed early in heavy write loads. Thanks Anuj Wadehra Sent from Yahoo Mail on Android From:"Robert Wille" <rwi...@fold3.com> Date:Sat, 13 Jun, 2015 at 8:29 pm Subject:Re: Dropped mutation messages Internode messages which are received by a node, but do not get not to be processed within rpc_timeout are dropped rather than processed. As the coordinator node will no longer be waiting for a response. If the Coordinator node does not receive Consistency Level responses before the rpc_timeout it will return a TimedOutException to the client. I understand that, but that’s where this makes no sense. I’m running with RF=1, and CL=QUORUM, which means each update goes to one node, and I need one response for a success. I have many thousands of dropped mutation messages, but no TimedOutExceptions thrown back to the client. If I have GC problems, or other issues that are making my cluster unresponsive, I can deal with that. But having writes that fail and no error is clearly not acceptable. How is it possible to be getting errors and not be informed about them? Thanks Robert
