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.la...@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.pl...@gmail.com > <javascript:_e(%7B%7D,'cvml','eric.pl...@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.pl...@gmail.com >> <javascript:_e(%7B%7D,'cvml','eric.pl...@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.la...@nytimes.com >>> <javascript:_e(%7B%7D,'cvml','michael.la...@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.pl...@gmail.com> >>>> wrote: >>>> >>>>> read_repair_chance: 0 >>>>> dclocal_read_repair_chance: 0.1 >>>>> >>>>> >>>>> On Wednesday, September 9, 2015, Laing, Michael < >>>>> michael.la...@nytimes.com> wrote: >>>>> >>>>>> What are your read repair settings? >>>>>> >>>>>> On Tue, Sep 8, 2015 at 9:28 PM, Eric Plowe <eric.pl...@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.pl...@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 <rc...@eventbrite.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, Sep 8, 2015 at 4:40 PM, Eric Plowe <eric.pl...@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 >>>>>>>>> >>>>>>>>> >>>>>> >>>> >> >
