Re: write time for nulls is not consistent

Works fine either case on 3.0.12 Subroto > On Jul 18, 2017, at 2:41 PM, kurt greaves wrote: > > can you try select a, writetime(b) from test.t > I heard of an issue recently where cqlsh reports null incorrectly if you > query a column twice, wondering if it extends to

Debugging requests blocking because of max_queued_native_transport_requests

A deployment of mine is hitting the cassandra.max_queued_native_transport_requests limit quite often. I'd like to trace which batch of requests caused Cassandra to go over the limit, by adding some logs to Cassandra 2.2. I was considering setting some thread local flag when we block and

Re: write time for nulls is not consistent

can you try select a, writetime(b) from test.t I heard of an issue recently where cqlsh reports null incorrectly if you query a column twice, wondering if it extends to this case with writetime.

Re: Moving from DSE to Cassandra.

yes. From: Harikrishnan Pillai Sent: Tuesday, July 18, 2017 12:30 PM To: user@cassandra.apache.org Subject: EXT: Re: Moving from DSE to Cassandra. Moving away from DSE to apache cassandra is easy. If there are any keyspace with

Re: Moving from DSE to Cassandra.

So once i migrate to open source cassandra do i really need DSE keyspace ?? can't i just remove it ?? Thanks Pranay. On Tue, Jul 18, 2017 at 3:30 PM, Harikrishnan Pillai < hpil...@walmartlabs.com> wrote: > Moving away from DSE to apache cassandra is easy. > > If there are any keyspace with

Re: Moving from DSE to Cassandra.

Moving away from DSE to apache cassandra is easy. If there are any keyspace with "EverywhereStrategy" strategies, change them to "NetworkTopologyStrategy" first. particularly DSE system. Start in opensource mode and run sstable upgrade if needed. Regards Hari

Re: write time for nulls is not consistent

insert into test.t (a ) values ('v’); > On Jul 18, 2017, at 2:28 PM, Jonathan Haddad wrote: > > Since you didn't show all the queries you used, I made an assumption that > you've inserted other data. Where is the query that inserted a="v"? I don't > know how to answer

Re: write time for nulls is not consistent

Since you didn't show all the queries you used, I made an assumption that you've inserted other data. Where is the query that inserted a="v"? I don't know how to answer the question if you're not actually showing how to reproduce the problem. On Tue, Jul 18, 2017 at 12:24 PM Nitan Kainth

Moving from DSE to Cassandra.

Planning to move from DSE to open source cassandra. What will be better way to do it. 1) I am thinking of introducing new datacenter with apache cassandra and replicating to that DC and after data replication remove DSE cassandra DC 2) Upgrading from current DSE version to later version of

Re: write time for nulls is not consistent

Jonathan, Please notice last rows with partition key values (w,v and t). they were inserted same way and has write time values > On Jul 18, 2017, at 2:22 PM, Jonathan Haddad wrote: > > This looks like expected behavior to me. You aren't inserting a value for b. > Since

Re: write time for nulls is not consistent

This looks like expected behavior to me. You aren't inserting a value for b. Since there's no value, there's also no writetime. On Tue, Jul 18, 2017 at 12:15 PM Nitan Kainth wrote: > Hi, > > We see that null columns have writetime(column) populated for few columns > and

write time for nulls is not consistent

Hi, We see that null columns have writetime(column) populated for few columns and shows null for few other. Is it any bug or something else? CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 'us-east': '2'} AND durable_writes = true; CREATE TABLE test.t ( a

Re: Cassandra UNREACHABLE node

I’m not sure it’s going to help you a lot as the issue is still open and there is not a lot of info in the ticket but your issue looks a lot like this JIRA to me: https://issues.apache.org/jira/browse/CASSANDRA-13363 Cheers Ben On Tue, 18 Jul 2017 at 17:46 Shashikant Kulkarni (शशिकांत कुलकर्णी)

Cassandra UNREACHABLE node

Hello All, I have Cassandra v3.9, with 3 nodes in cluster. Replication factor 2 10.0.0.11,10.0.0.12,10.0.0.13 10.0.0.11,10.0.0.12 are seed nodes What could be the possible reasons for following error in /etc/cassandra/conf/debug.log The error is DEBUG [RMI TCP Connection(174)-127.0.0.1]

FW: unsubscribe

Thanks and regards, Bhupendra Baraiya Continuum Managed Services, LLC. p: 902-933-0019 e: bhupendra.bara...@continuum.net w: continuum.net