incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
Subject Re: Enormous counter problem?
Date Tue, 09 Aug 2011 09:32:08 GMT
Yes, if you can reproduce easily, please see if 0.8.3 fixes it for by
any chance.
Otherwise, please open a JIRA ticket with as much info on how to reproduce.

--
Sylvain

On Tue, Aug 9, 2011 at 11:04 AM, Andrii Denysenko <andrden@gmail.com> wrote:
> Try 0.8.3
> They fixed https://issues.apache.org/jira/browse/CASSANDRA-2968 - and this
> produced erroneous records for counters.
> Not sure this is exactly yours, but similar.
>
> On Tue, Aug 9, 2011 at 5:28 AM, Boris Yen <yulinyen@gmail.com> wrote:
>>
>> Hi,
>> I am not sure if this is a bug or we use the counter the wrong way, but I
>> keep getting a enormous counter number in our deployment. After a few tries,
>> I am finally able to reproduce it. The following are the settings of my
>> development:
>> -----------------------------------------------------
>> I have two-node cluster with the following keyspace and column family
>> settings.
>> Cluster Information:
>>    Snitch: org.apache.cassandra.locator.SimpleSnitch
>>    Partitioner: org.apache.cassandra.dht.RandomPartitioner
>>    Schema versions:
>> 63fda700-c243-11e0-0000-2d03dcafebdf: [172.17.19.151, 172.17.19.152]
>> Keyspace: test:
>>   Replication Strategy:
>> org.apache.cassandra.locator.NetworkTopologyStrategy
>>   Durable Writes: true
>>     Options: [datacenter1:2]
>>   Column Families:
>>     ColumnFamily: testCounter (Super)
>>     "APP status information."
>>       Key Validation Class: org.apache.cassandra.db.marshal.BytesType
>>       Default column value validator:
>> org.apache.cassandra.db.marshal.CounterColumnType
>>       Columns sorted by:
>> org.apache.cassandra.db.marshal.BytesType/org.apache.cassandra.db.marshal.BytesType
>>       Row cache size / save period in seconds: 0.0/0
>>       Key cache size / save period in seconds: 200000.0/14400
>>       Memtable thresholds: 1.1578125/1440/247 (millions of ops/MB/minutes)
>>       GC grace seconds: 864000
>>       Compaction min/max thresholds: 4/32
>>       Read repair chance: 1.0
>>       Replicate on write: true
>>       Built indexes: []
>> Then, I use a test program based on hector to add a counter column
>> (testCounter[sc][column]) 1000 times. In the middle the adding process, I
>> intentional shut down the node 172.17.19.152. In addition to that, the test
>> program is smart enough to switch the consistency level from Quorum to One,
>> so that the following adding actions would not fail.
>> After all the adding actions are done, I start the cassandra
>> on 172.17.19.152, and I use cassandra-cli to check if the counter is correct
>> on both nodes, and I got a result 1001 which should be reasonable because
>> hector will retry once. However, when I shut down 172.17.19.151 and
>> after 172.17.19.152 is aware of 172.17.19.151 is down, I try to start the
>> cassandra on 172.17.19.151 again. Then, I check the counter again, this time
>> I got a result 481387 which is so wrong.
>> I was wondering if anyone could explain why this happens, is this a bug or
>> do I use the counter the wrong way?.
>> Regards
>> Boris
>
>
> --
> Regards,
> Andriy Denysenko
>
>

Mime
View raw message