Re: Driver consistency issue

Please don’t cross-post multiple lists. Datastax list removed Abishek, do you have auth enabled? Does the system auth keyspace have rf=3? -- Jeff Jirsa > On Feb 27, 2018, at 2:59 AM, Nicolas Guyomar > wrote: > > Hi, > > Adding the java-driver ML for further question, because this does lo

Re: Driver consistency issue

Hi Abhishek & everyone else, might it be related to https://issues.apache.org/jira/browse/CASSANDRA-7868 ? regards, Christian On Tue, Feb 27, 2018 at 12:46 PM, Abhishek Kumar Maheshwari < abhishek.maheshw...@timesinternet.in> wrote: > Hi, > > Not always. Randomly i am getting this exception.

Re: Driver consistency issue

Hi, Not always. Randomly i am getting this exception. (one observation, mostly i got this exception when i add new node in cluster.) On Tue, Feb 27, 2018 at 4:29 PM, Nicolas Guyomar wrote: > Hi, > > Adding the java-driver ML for further question, because this does look > like a bug > > Are you

Re: Driver consistency issue

Hi, Adding the java-driver ML for further question, because this does look like a bug Are you able to reproduce it a clean environnement using the same C* version and driver version ? On 27 February 2018 at 10:05, Abhishek Kumar Maheshwari < abhishek.maheshw...@timesinternet.in> wrote: > Hi Al

Re: Driver consistency issue

Hi Alex, i have only One DC (with name DC1) and have only one keyspace. So i dont think so both of the scenario is possible. (yes in my case QUORUM is equivalent of ALL) cqlsh> SELECT * FROM system_schema.keyspaces where keyspace_name='adlog' ; keyspace_name | durable_writes | replication

Re: Driver consistency issue

On Tue, Feb 27, 2018 at 9:45 AM, Abhishek Kumar Maheshwari < abhishek.maheshw...@timesinternet.in> wrote: > > i have a KeySpace in Cassandra (cassandra version 3.0.9- total 12 Servers > )With below definition: > > {'DC1': '2', 'class': 'org.apache.cassandra.locator. > NetworkTopologyStrategy'} > >

Driver consistency issue

Hi All, i have a KeySpace in Cassandra (cassandra version 3.0.9- total 12 Servers )With below definition: {'DC1': '2', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'} Some time i am getting below exception com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra tim

Re: Read/Write consistency issue

, 2014 at 4:59 PM To: Subject: Re: Read/Write consistency issue As was pointed out earlier, Consistency.ALL is still subject to the possibility of clock drift between nodes, and there is also the problem of using the exact same timestamp, which is increasingly likely to happen the faster you update

Re: Read/Write consistency issue

old is the value that was read from the column. val is the value that needs to be added to it. new is (old + val) that is written back to the column. regards On Fri, Jan 10, 2014 at 4:36 PM, Andrey Ilinykh wrote: > For single thread, consistency ALL it should work. I believe you do > somethin

Re: Read/Write consistency issue

For single thread, consistency ALL it should work. I believe you do something different. What are these three numbers exactly? old=60616 val =19 new =60635 On Fri, Jan 10, 2014 at 1:50 PM, Manoj Khangaonkar wrote: > Hi > > Using Cassandra 2.0.0. > 3 node cluster > Replication 2. > Using consiste

Re: Read/Write consistency issue

>>> On Fri, Jan 10, 2014 at 2:35 PM, Robert Wille wrote: >>> >>>> Actually, locking won’t fix the problem. He’s getting the problem on a >>>> single thread. >>>> >>>> I’m pretty sure that if updates can occur within the same millisecond

Re: Read/Write consistency issue

> >>> On Fri, Jan 10, 2014 at 2:35 PM, Robert Wille wrote: >>> >>>> Actually, locking won’t fix the problem. He’s getting the problem on a >>>> single thread. >>>> >>>> I’m pretty sure that if updates can occur within the same millisec

Re: Read/Write consistency issue

its epidermal layer”.. > > > > *From:* Tupshin Harper [mailto:tups...@tupshin.com] > *Sent:* Friday, January 10, 2014 5:13 PM > > *To:* user@cassandra.apache.org > *Subject:* Re: Read/Write consistency issue > > > > It is bad because of the risk of concurrent m

Re: Read/Write consistency issue

is clock skew), there is literally nothing you can do to >>> make this pattern work. >>> >>> Robert >>> >>> From: Todd Carrico >>> Reply-To: >>> Date: Friday, January 10, 2014 at 3:28 PM >>> To: "user@cassandra.apache.org&quo

RE: Read/Write consistency issue

m: Tupshin Harper [mailto:tups...@tupshin.com] Sent: Friday, January 10, 2014 5:13 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue It is bad because of the risk of concurrent modifications. If you don't have some kind of global lock on the document/row, then 2 readers mig

RE: Read/Write consistency issue

, January 10, 2014 4:52 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue Interested in knowing more on why read-before-write is an anti-pattern. In the next month or so, I intend to use Cassandra as a doc store. One very common operation will be to read the document, make a

Re: Read/Write consistency issue

Robert > > From: Steven A Robenalt > Reply-To: > Date: Friday, January 10, 2014 at 3:41 PM > > To: > Subject: Re: Read/Write consistency issue > > My understanding is that it's generally a Cassandra anti-pattern to do > read-before-write in any case, not jus

Re: Read/Write consistency issue

re is literally nothing you can do to >> make this pattern work. >> >> Robert >> >> From: Todd Carrico >> Reply-To: >> Date: Friday, January 10, 2014 at 3:28 PM >> To: "user@cassandra.apache.org" >> Subject: RE: Read/Write consistency is

Re: Read/Write consistency issue

rapid repeated writing is not an issue. Why would this be bad? Robert From: Steven A Robenalt Reply-To: Date: Friday, January 10, 2014 at 3:41 PM To: Subject: Re: Read/Write consistency issue My understanding is that it's generally a Cassandra anti-pattern to do read-before-write i

Re: Read/Write consistency issue

ake this pattern work. > > Robert > > From: Todd Carrico > Reply-To: > Date: Friday, January 10, 2014 at 3:28 PM > To: "user@cassandra.apache.org" > Subject: RE: Read/Write consistency issue > > That, or roll your own locking. Means multiple updates, but

RE: Read/Write consistency issue

Is it possible to pin to a node, instead of letting the client find the next node (round robin)? Sorry, a C* noob here... tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, January 10, 2014 4:35 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue Actually

Re: Read/Write consistency issue

: Date: Friday, January 10, 2014 at 3:28 PM To: "user@cassandra.apache.org" Subject: RE: Read/Write consistency issue That, or roll your own locking. Means multiple updates, but it works reliably. tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, January 10, 2014

RE: Read/Write consistency issue

That, or roll your own locking. Means multiple updates, but it works reliably. tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, January 10, 2014 4:25 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue Cassandra is a last-write wins kind of a deal. The last

Re: Read/Write consistency issue

at 2:50 PM To: Subject: Read/Write consistency issue Hi Using Cassandra 2.0.0. 3 node cluster Replication 2. Using consistency ALL for both read and writes. I have a single thread that reads a value, updates it and writes it back to the table. The column type is big int. Updating counts for a

Read/Write consistency issue

Hi Using Cassandra 2.0.0. 3 node cluster Replication 2. Using consistency ALL for both read and writes. I have a single thread that reads a value, updates it and writes it back to the table. The column type is big int. Updating counts for a timestamp. With single thread and consistency ALL , I e

Re: Cassandra consistency issue on cluster system

If you are reading at QUOURM there is no problem, this is how eventual consistency works in Cassandra. The coordinator will resolve the differences between and the column with the higher timestamp will win. If the delete was applied to less then CL nodes the client should have received a Time

Cassandra consistency issue on cluster system

*Background*: My application is running on a cluster system(which have 4 nodes), and system time of these four nodes are synchronizing by NTP. I use Write.QUORUM and Read.QUORUM strategy. The probability of this problem is not very high. Cassandra version is 1.0.3, I have tried Cassandra 1.1.1, thi

Re: Consistency issue

I'm using the Hector defaults, which are QUORUM for reads and writes. On 9/3/2010 3:18 PM, Nick Telford wrote: Are you using QUORUM for both writes and reads? The behaviour you're seeing sounds like something I'd expect to see if you used NONE for writes. On 3 September 2010 14:12, Hugo

Re: Consistency issue

Are you using QUORUM for both writes and reads? The behaviour you're seeing sounds like something I'd expect to see if you used NONE for writes. On 3 September 2010 14:12, Hugo wrote: > I'm using QUORUM, but in my single-node setup this doesn't matter IMHO. > > > On 9/3/2010 1:51 PM, Nick Telf

Re: Consistency issue

I'm using QUORUM, but in my single-node setup this doesn't matter IMHO. On 9/3/2010 1:51 PM, Nick Telford wrote: Which ConsistencyLevels did you use for your batchMutate() and getSlice() operations? ConsistencyLevels directly dictate the level of consistency you will get with your data. Re

Re: Consistency issue

Which ConsistencyLevels did you use for your batchMutate() and getSlice() operations? ConsistencyLevels directly dictate the level of consistency you will get with your data. Regards, Nick Telford On 3 September 2010 12:03, Hugo wrote: > Hi, > > I'm performing tests with Cassandra 0.6.5 with

Consistency issue

Hi, I'm performing tests with Cassandra 0.6.5 with Hector 0.6.0-14 on a single machine (one node cluster). I've noticed an issue with consistency. In my tests I perform a KeySpace.batchMutate() to update a column and immediately after that I perform a KeySpace.getSlice() on the same column