cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4436) Counters in columns don't preserve correct values after cluster restart
Date Tue, 24 Jul 2012 09:00:37 GMT

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

Sylvain Lebresne updated CASSANDRA-4436:
----------------------------------------

    Attachment: 4436-1.1-2.txt
                4436-1.0-2.txt

bq. Looks like skipCompacted in Directories.SSTableLister can be removed (since we scrubDataDirectories
on startup and no new compacted components will be created).

True, though there is the (arguably remote) possibility that people call loadNewSSTables()
(or the offline scrub from CASSANDRA-4441) on sstables having some -Compacted components.
So I would prefer leaving it in 1.1 and removing it during the merge to trunk, just to be
sure minor upgrade are as little disrupting as can be.

bq. Using a List means we can add an ancestor multiple times. Suggest using a Set instead.

But we won't have the same ancestor multiple times. Otherwise that would be a bug (and at
least for counters, a particularly bad one). But for sanity I've added an assertion to check
this doesn't happen (I've a list however, I figured that since the list will be small, the
difference between List.contains() and Set.contains() will be negligeable, and it's checked
in an assertion and only once a the sstable creation. On the other Lists have a smaller memory
footprint. Though I admit in either case we're talked minor differences).

bq. would prefer Ancestor to LiveAncestor, since we only check liveness at creation time,
so "Live" is misleading when iterating over them later.

Renamed.

bq. the deleting code feels more at home in CFS constructor than addInitialSSTables.

Moved.

bq. tracker parameter is unused now in SSTR.open

Removed. I realized that setTrackedBy was already always call through the DataTracker.addNewSSTablesSize,
so I also removed the call duplication.

                
> Counters in columns don't preserve correct values after cluster restart
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-4436
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4436
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.10
>            Reporter: Peter Velas
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.3
>
>         Attachments: 4436-1.0-2.txt, 4436-1.0.txt, 4436-1.1-2.txt, 4436-1.1.txt, increments.cql.gz
>
>
> Similar to #3821. but affecting normal columns. 
> Set up a 2-node cluster with rf=2.
> 1. Create a counter column family and increment a 100 keys in loop 5000 times. 
> 2. Then make a rolling restart to cluster. 
> 3. Again increment another 5000 times.
> 4. Make a rolling restart to cluster.
> 5. Again increment another 5000 times.
> 6. Make a rolling restart to cluster.
> After step 6 we were able to reproduce bug with bad counter values. 
> Expected values were 15 000. Values returned from cluster are higher then 15000 + some
random number.
> Rolling restarts are done with nodetool drain. Always waiting until second node discover
its down then kill java process. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message