The comment around line 448 in StorageProxy
// We do the replication on another stage because it
involves a read (see CM.makeReplicationMutation)
// and we want to avoid blocking too much the MUTATION stage
The read happens on another stage, it is not part
yeah, then maybe we can make that a silent omission. less desirable, but
still better than unpredicted behavior. (this is not that bad: currently you
can't know whether a write result really reached a quorum, i.e. become
"effective", anyway)
regarding "we never look at SStables", I think right no
Sorry that was a typo the query I had in my test case reads as follows:
$query = "CREATE COLUMNFAMILY smoke (KEY text PRIMARY KEY, monkey text)
WITH comparator = text AND default_validation = text";
thanks for your response, still have the same issue. it seems thrift php
interface exception aren
I often suggest people think about using something like JSON for data the looks
relatively unchanging, or looks like it is always worked on as a single entity
for a couple of reasons.
1. Cassandra does not need to know about every atomic piece of data in your
model. Obviously there are some goo
Without commenting on the other parts of the design, this part is not possible
"attempts to add to a dead counter throws an exception "
All write operations are no look operations (write to the log, update
memtables) we never look at the SSTables. It goes against the architecture of
the write p
Specify a comparator and sub_comparator for the CF, the cli will then use these
to format the values correctly.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 29 May 2011, at 18:02, Mubarak Seyed wrote:
> I have a Counter defin
You've not talked about how you are doing the tests (or i missed it).
With 6 nodes and RF 3 when you read at ONE there is a 50% chance of the data
read been served locally. In which case the request will return to the client
very quickly. Allowing X number of clients to make Y number of request
sorry in the notation, instead of "ttl" I mean "timestamp"
On Sun, May 29, 2011 at 12:24 AM, Yang wrote:
> sorry to beat on the dead horse.
>
> I looked at the link referred from #2103 :
> https://issues.apache.org/jira/browse/CASSANDRA-2101
> I agree with the reasoning in #2101 that the ultima
errata:
"so c(123) means a counter column of ttl=1," > "so c(123) means a
counter column of ttl=123,"
On Sun, May 29, 2011 at 12:24 AM, Yang wrote:
> sorry to beat on the dead horse.
>
> I looked at the link referred from #2103 :
> https://issues.apache.org/jira/browse/CASSANDRA-2101
> I ag
sorry to beat on the dead horse.
I looked at the link referred from #2103 :
https://issues.apache.org/jira/browse/CASSANDRA-2101
I agree with the reasoning in #2101 that the ultimate issue is that delete
and counter adds are not commutative. since by definition we can't achieve
predictable behavio
10 matches
Mail list logo
