[jira] [Updated] (CASSANDRA-9641) Occasional timeouts with blockFor=all for LOCAL_QUORUM query

2015-11-12 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-9641:
-
Component/s: Coordination

> Occasional timeouts with blockFor=all for LOCAL_QUORUM query
> 
>
> Key: CASSANDRA-9641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9641
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We have a keyspace using NetworkTopologyStrategy with options DC1:3, DC2:3. 
> Our tables have
> read_repair_chance = 0.0
> dclocal_read_repair_chance = 0.1
> speculative_retry = ’99.0PERCENTILE'
> and all reads are at LOCAL_QUORUM. On 2.0.11, we occasionally see this 
> timeout:
> Cassandra timeout during read query at consistency ALL (6 responses were 
> required but only 5 replica responded)
> (sometimes only 4 respond). The ALL is probably due to CASSANDRA-7947 if this 
> occurs during a digest mismatch, but what is interesting is it is expecting 6 
> responses i.e. blockFor is set to all replicas. I can’t see how this should 
> happen. From the code it should never set blockFor to more than 4 (although 4 
> is still wrong - I'll make a separate JIRA for that).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9641) Occasional timeouts with blockFor=all for LOCAL_QUORUM query

2015-11-12 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-9641:
-
Fix Version/s: 3.0.x
   2.2.x
   2.1.x

> Occasional timeouts with blockFor=all for LOCAL_QUORUM query
> 
>
> Key: CASSANDRA-9641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9641
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We have a keyspace using NetworkTopologyStrategy with options DC1:3, DC2:3. 
> Our tables have
> read_repair_chance = 0.0
> dclocal_read_repair_chance = 0.1
> speculative_retry = ’99.0PERCENTILE'
> and all reads are at LOCAL_QUORUM. On 2.0.11, we occasionally see this 
> timeout:
> Cassandra timeout during read query at consistency ALL (6 responses were 
> required but only 5 replica responded)
> (sometimes only 4 respond). The ALL is probably due to CASSANDRA-7947 if this 
> occurs during a digest mismatch, but what is interesting is it is expecting 6 
> responses i.e. blockFor is set to all replicas. I can’t see how this should 
> happen. From the code it should never set blockFor to more than 4 (although 4 
> is still wrong - I'll make a separate JIRA for that).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9641) Occasional timeouts with blockFor=all for LOCAL_QUORUM query

2015-09-16 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-9641:
-
Fix Version/s: (was: 2.0.x)

> Occasional timeouts with blockFor=all for LOCAL_QUORUM query
> 
>
> Key: CASSANDRA-9641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9641
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Richard Low
>
> We have a keyspace using NetworkTopologyStrategy with options DC1:3, DC2:3. 
> Our tables have
> read_repair_chance = 0.0
> dclocal_read_repair_chance = 0.1
> speculative_retry = ’99.0PERCENTILE'
> and all reads are at LOCAL_QUORUM. On 2.0.11, we occasionally see this 
> timeout:
> Cassandra timeout during read query at consistency ALL (6 responses were 
> required but only 5 replica responded)
> (sometimes only 4 respond). The ALL is probably due to CASSANDRA-7947 if this 
> occurs during a digest mismatch, but what is interesting is it is expecting 6 
> responses i.e. blockFor is set to all replicas. I can’t see how this should 
> happen. From the code it should never set blockFor to more than 4 (although 4 
> is still wrong - I'll make a separate JIRA for that).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9641) Occasional timeouts with blockFor=all for LOCAL_QUORUM query

2015-06-23 Thread Philip Thompson (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philip Thompson updated CASSANDRA-9641:
---
Fix Version/s: 2.0.x

 Occasional timeouts with blockFor=all for LOCAL_QUORUM query
 

 Key: CASSANDRA-9641
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9641
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low
 Fix For: 2.0.x


 We have a keyspace using NetworkTopologyStrategy with options DC1:3, DC2:3. 
 Our tables have
 read_repair_chance = 0.0
 dclocal_read_repair_chance = 0.1
 speculative_retry = ’99.0PERCENTILE'
 and all reads are at LOCAL_QUORUM. On 2.0.11, we occasionally see this 
 timeout:
 Cassandra timeout during read query at consistency ALL (6 responses were 
 required but only 5 replica responded)
 (sometimes only 4 respond). The ALL is probably due to CASSANDRA-7947 if this 
 occurs during a digest mismatch, but what is interesting is it is expecting 6 
 responses i.e. blockFor is set to all replicas. I can’t see how this should 
 happen. From the code it should never set blockFor to more than 4 (although 4 
 is still wrong - I'll make a separate JIRA for that).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)