Yeah, that's what I did. Just wanted to verify it that will indeed turn it off.

On Wednesday, September 9, 2015, Laing, Michael <michael.laing@nytimes.com> wrote:
"alter table test.test_root WITH speculative_retry = '0.0PERCENTILE';"

seemed to work for me with C* version 2.1.7

On Wed, Sep 9, 2015 at 10:11 AM, Eric Plowe <eric.plowe@gmail.com> wrote:
Would this work:

ALTER TABLE session_state WITH speculative_retry = '0ms';
ALTER TABLE session_state WITH speculative_retry = '0PERCENTILE';

I can't set it to 0, but was wondering if these would have the same effect? 

~Eric

On Wed, Sep 9, 2015 at 8:19 AM, Eric Plowe <eric.plowe@gmail.com> wrote:
Interesting. I'll give it a try and report back my findings.

Thank you, Michael.


On Wednesday, September 9, 2015, Laing, Michael <michael.laing@nytimes.com> wrote:
Perhaps a variation on https://issues.apache.org/jira/browse/CASSANDRA-9753?

You could try setting speculative retry to 0 to avoid cross-dc reads.

On Wed, Sep 9, 2015 at 7:55 AM, Eric Plowe <eric.plowe@gmail.com> wrote:
read_repair_chance: 0
dclocal_read_repair_chance: 0.1


On Wednesday, September 9, 2015, Laing, Michael <michael.laing@nytimes.com> wrote:
What are your read repair settings?

On Tue, Sep 8, 2015 at 9:28 PM, Eric Plowe <eric.plowe@gmail.com> wrote:
To further expand. We have two data centers, Miami and Dallas. Dallas is our disaster recovery data center. The cluster has 12 nodes, 6 in Miami and 6 in Dallas. The servers in Miami only read/write to Miami using data center aware load balancing policy of the driver. We have the problem when writing and reading to the Miami cluster with LOCAL_QUORUM.

Regards,

Eric 

On Tuesday, September 8, 2015, Eric Plowe <eric.plowe@gmail.com> wrote:
Rob,

All writes/reads are happening from DC1. DC2 is a backup. The web app does not handle live requests from DC2.

Regards,

Eric Plowe

On Tuesday, September 8, 2015, Robert Coli <rcoli@eventbrite.com> wrote:
On Tue, Sep 8, 2015 at 4:40 PM, Eric Plowe <eric.plowe@gmail.com> wrote:
I'm using Cassandra as a storage mechanism for session state persistence for an ASP.NET web application. I am seeing issues where the session state is persisted on one page (setting a value: Session["key"] = "value" and when it redirects to another (from a post back event) and check for the existence of the value that was set, it doesn't exist.

It's a 12 node cluster with 2 data centers (6 and 6) running 2.1.9. The key space that the column family lives has a RF of 3 for each data center. The session state provider is using the the datastax csharp driver v2.1.6. Writes and reads are at LOCAL_QUORUM. 

1) Write to DC_A with LOCAL_QUORUM
2) Replication to DC_B takes longer than it takes to...
3) Read from DC_B with LOCAL_QUORUM, do not see the write from 1)

If you want to be able to read your writes from DC_A in DC_B, you're going to need to use EACH_QUORUM.

=Rob