cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Yen <yulin...@gmail.com>
Subject Re: Enormous counter problem?
Date Tue, 09 Aug 2011 09:44:10 GMT
ticket opened, https://issues.apache.org/jira/browse/CASSANDRA-3006

On Tue, Aug 9, 2011 at 5:38 PM, Boris Yen <yulinyen@gmail.com> wrote:

> Actually, I reproduced this on 0.8.3, so it seems to me that it is not
> fixed yet.
>
> Boris
>
>
> On Tue, Aug 9, 2011 at 5:32 PM, Sylvain Lebresne <sylvain@datastax.com>wrote:
>
>> 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