Re: Blocking behavior of StorageProxy.fetchRows

2016-01-08 Thread Russell Bradberry
While using LOCAL_QUORUM may be a solution in a lot of use cases, there are definitely use cases where reading at full QUORUM is required, think finance, medical, military. I think for these types of use cases using non blocking behavior will be an incredible improvement in performance. Even for

Re: Blocking behavior of StorageProxy.fetchRows

2016-01-08 Thread Jonathan Haddad
Use local quorum, don't talk to remote dcs. On Fri, Jan 8, 2016 at 1:41 PM Dominic Chevalier wrote: > Hello, > > tldr; > > It looks like StorageProxy.fetchRows blocking for read responses can get > pretty bad during quorum reads involving many geographically distant data > centers. If this is tru

Re: [VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Josh McKenzie
+1 On Fri, Jan 8, 2016 at 4:12 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.2. > > sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6 > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative > Artifacts: > > https://reposi

Re: [VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Jake Luciani
Linking the Datastax Test Engineering report for this release (Something we will likely include from now on) https://docs.google.com/document/d/1n-xNTOJYN-KI1xH14CsReLBt8QbEWyB0XX7qDq1nehw/edit# On Fri, Jan 8, 2016 at 4:12 PM, Jake Luciani wrote: > > I propose the following artifacts for releas

Blocking behavior of StorageProxy.fetchRows

2016-01-08 Thread Dominic Chevalier
Hello, tldr; It looks like StorageProxy.fetchRows blocking for read responses can get pretty bad during quorum reads involving many geographically distant data centers. If this is true, why doesn't the coordinator handle replies asynchronously to keep over all throughput up? Long; I'm running a

Re: [VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Aleksey Yeschenko
+1 --  AY On 8 January 2016 at 21:13:25, Jake Luciani (j...@apache.org) wrote: I propose the following artifacts for release as 3.2. sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative Artifacts

Re: [VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Brandon Williams
+1 On Fri, Jan 8, 2016 at 3:12 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.2. > > sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6 > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative > Artifacts: > > https://reposi

Re: [VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Jonathan Ellis
+1 On Fri, Jan 8, 2016 at 3:12 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.2. > > sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6 > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative > Artifacts: > > https://reposi

[VOTE] Release Apache Cassandra 3.2

2016-01-08 Thread Jake Luciani
I propose the following artifacts for release as 3.2. sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1096/org/apache/cas

Re: Proposal: deprecate Thrift now and remove support in 4.0

2016-01-08 Thread Jonathan Ellis
I've updated NEWS for 3.2 with a deprecation announcement. I've also sent an announcement to the users list. On Mon, Dec 28, 2015 at 8:26 AM, Jonathan Ellis wrote: > Thrift has been officially frozen for almost two years and unofficially > for longer. [1] Meanwhile, maintaining Thrift support

Re: Proposal: deprecate Thrift now and remove support in 4.0

2016-01-08 Thread Gary Dusbabek
Super belated +1. It's time. Gary. On Mon, Dec 28, 2015 at 8:26 AM, Jonathan Ellis wrote: > Thrift has been officially frozen for almost two years and unofficially for > longer. [1] Meanwhile, maintaining Thrift support through changes like > 8099 has been a substantial investment. > > I propo