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"
Date:Sat, 13 Jun, 2015 at 11:31 pm
Subject:Re: Dropped mutation messages
I think the messages dropped are the asynchronous ones required t
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 memta
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
I meant to say I’m *not* overloading my cluster.
On Jun 12, 2015, at 6:52 PM, Robert Wille wrote:
> I am preparing to migrate a large amount of data to Cassandra. In order to
> test my migration code, I’ve been doing some dry runs to a test cluster. My
> test cluster is 2.0.15, 3 nodes, RF=1 a
> What should be the path to investigate this?
Dropped messages are a symptom of other problems.
Look for the GCInspector logging lots of ParNew, or the IO system being
overloaded, or large (1000's) read or write batches from the client.
Cheers
-
Aaron Morton
Freelance Cassandr
Hello Arthur,
What do you mean by "The queries need to be lightened"?
Thanks,
Shahb
On Tue, Jun 18, 2013 at 8:47 PM, Arthur Zubarev wrote:
> Cem hi,
>
> as per http://wiki.apache.org/cassandra/FAQ#dropped_messages
>
>
> Internode messages which are received by a node, but do not get not to b
Cem hi,
as per http://wiki.apache.org/cassandra/FAQ#dropped_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
no
