By the way, I wonder if a rolling restart is still possible when I am using counters ? Don't we lose the SPOF too, considering that counters are wrong every time we retry to write them with the client ?
Can we have a hope that counters will be replayed as safely as a classical data someday ? Do someone still work on jiras like issues.apache.org/jira/browse/CASSANDRA-2495 ? I thought that replaying a write from the client didn't lead to over-counts contrary to the internal cassandra replay from commitlog.I just made a new connection pool with retries / 2 and timeouts * 4. I hope it will improve the accuracy of my counters.Anyways, thank you for answering that fast.
Alain2011/12/16 Tyler Hobbs <firstname.lastname@example.org>Probably quite a few of them are coming from automatic retries by phpcassa. When working with counters, I recommend minimizing retries and/or increasing timeouts. Usually this means you want to use a separate connection pool with different settings just for counters.
By the way, this advice applies to other clients as well.--On Wed, Dec 14, 2011 at 10:29 AM, Alain RODRIGUEZ <email@example.com> wrote:
Hi everybody.I'm using a lot of counters to make statistics on a 4 nodes cluster (ec2 m1.small) with phpcassa (cassandra v1.0.2).I store some events and increment counters at the same time.Counters give me over-counts compared with the count of every corresponding events.I sure that my non-counters counts are good.I'm not sure why these over-counts happen, but I heard that recovering from commitlogs can produce this.I have some timeouts on phpcassa which are written in my apache logs while a compaction is running. However I am always able to write at Quorum, so I guess I shouldn't have to recover from cassandra commitlogs.Where can these over-counts come from ?Alain