Thanks a lot Ben. This makes sense but feel bad that we don't have a solution 
yet. We can try consistency level one but that will be against general rule for 
having local_quorum for production. Also, consistency ONE will not guarantee 0 
race condition.
Is there any better solution?
    On Saturday, July 21, 2018, 8:27:57 PM CDT, Ben Slater 
<ben.sla...@instaclustr.com> wrote:  
 
 Note that that writetimeout exception can be C*s way of telling you when there 
is contention on a LWT (rather than actually timing out). See 
https://issues.apache.org/jira/browse/CASSANDRA-9328
CheersBen
On Sun, 22 Jul 2018 at 11:20 Goutham reddy <goutham.chiru...@gmail.com> wrote:

Hi,As it is a single partition key, try to update the key with only partition 
key instead of passing other columns. And try to set consistency level ONE. 
Cheers,Goutham.
On Fri, Jul 20, 2018 at 6:57 AM learner dba <cassandra...@yahoo.com.invalid> 
wrote:

 Anybody has any ideas about this? This is happening in production and we 
really need to fix it.
    On Thursday, July 19, 2018, 10:41:59 AM CDT, learner dba 
<cassandra...@yahoo.com.INVALID> wrote:  
 
  Our foreignid is unique idetifier and we did check for wide partitions; 
cfhistorgrams show all partitions are evenly sized:

Percentile  SSTables     Write Latency      Read Latency    Partition Size      
  Cell Count

                              (micros)          (micros)           (bytes)      
            

50%             0.00             29.52              0.00              1916      
          12

75%             0.00             42.51              0.00              2299      
          12

95%             0.00             61.21              0.00              2759      
          14

98%             0.00             73.46              0.00              2759      
          17

99%             0.00             88.15              0.00              2759      
          17

Min             0.00              9.89              0.00               150      
           2

Max             0.00             88.15              0.00           7007506      
       42510
any thing else that we can check?
    On Wednesday, July 18, 2018, 10:44:29 PM CDT, wxn...@zjqunshuo.com 
<wxn...@zjqunshuo.com> wrote:  
 
 Your partition key is foreignid. You may have a large partition. Why not use 
foreignid+timebucket as partition key?

 From: learner dbaDate: 2018-07-19 01:48To: User cassandra.apache.orgSubject: 
Timeout for only one keyspace in clusterHi,
We have a cluster with multiple keyspaces. All queries are performing good but 
write operation on few tables in one specific keyspace gets write timeout. 
Table has counter column and counter update query times out always. Any idea?

CREATE TABLE x.y (

    foreignid uuid,

    timebucket text,

    key text,

    timevalue int,

    value counter,

    PRIMARY KEY (foreignid, timebucket, key, timevalue)

) WITH CLUSTERING ORDER BY (timebucket ASC, key ASC, timevalue ASC)

    AND bloom_filter_fp_chance = 0.01

    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}

    AND comment = ''

    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}

    AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}

    AND crc_check_chance = 1.0

    AND dclocal_read_repair_chance = 0.1

    AND default_time_to_live = 0

    AND gc_grace_seconds = 864000

    AND max_index_interval = 2048

    AND memtable_flush_period_in_ms = 0

    AND min_index_interval = 128

    AND read_repair_chance = 0.0

    AND speculative_retry = '99PERCENTILE';

Query and Error:
UPDATE x.y SET value = value + 1 where foreignid = ? AND timebucket = ? AND key 
= ? AND timevalue = ?, err = &errors.errorString{s:\"gocql: no response 
received from cassandra within timeout period
I verified CL=local_serialWe had been working on this issue for many days; any 
help will be much appreciated.


    
-- 
Regards
Goutham Reddy

-- 

Ben Slater
Chief Product Officer



    

Read our latest technical blog posts here.

This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and 
Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally privileged 
information.  If you are not the intended recipient, do not copy or disclose 
its content, but please reply to this email immediately and highlight the error 
to the sender and then immediately delete the message.
  

Reply via email to