Was anyone able to reproduce this bug?
On Wed, Oct 6, 2010 at 6:19 PM, Jianing Hu wrote:
> I'm seeing cases where the count in slicerange predicate is not
> respected. This is only happening for super columns. I'm running
> Cassandra 0.6.4 in a single node.
>
> Step
I'm seeing cases where the count in slicerange predicate is not
respected. This is only happening for super columns. I'm running
Cassandra 0.6.4 in a single node.
Steps to reproduce, using the Keyspace1.Super1 CF:
* insert three super columns, bar1 bar 2, and bar3, under the same key
* delete bar1
We have a 3-node cluster of Cassandra 0.6.4, on one of them there's a
ton of error message like the following one:
WARN [MESSAGE-DESERIALIZER-POOL:1] 2010-08-18 04:10:57,767
MessageDeserializationTask.java (line 47) dropping message (1ms past
timeout)
The nod's load spikes and is super slow to rea
r the help.
On Mon, Aug 2, 2010 at 12:29 PM, Jonathan Ellis wrote:
> Yes, it is deterministic (but compaction could change which precise
> keys are affected)
>
> On Mon, Aug 2, 2010 at 1:15 PM, Jianing Hu wrote:
>> Does that bug cause *random* data read errors? Looks like it ma
fix size of row in spanned index entries (CASSANDRA-1056)
>
> You should upgrade to 0.6.4 (due out this weekend).
>
> On Wed, Jul 28, 2010 at 7:47 PM, Jianing Hu wrote:
>> We recently migrated part of our MySQL database to a 3-node Cassandra
>> cluster with a replication factor
gt; Is the read inconsistency against data that is frequently changing? Could it
> be a problem with the way the data is being stored?
>
> Aaron
>
>
>
>
> On 30 Jul, 2010,at 11:43 AM, Jianing Hu wrote:
>
> Hi Aaron,
>
> Thanks for the reply. Can you explain wha
be seeing this problem ?
> http://www.mail-archive.com/user@cassandra.apache.org/msg04831.html
>
> Aaron
>
>
> On 29 Jul, 2010,at 12:47 PM, Jianing Hu wrote:
>
> We recently migrated part of our MySQL database to a 3-node Cassandra
> cluster with a replication factor of 3.
We recently migrated part of our MySQL database to a 3-node Cassandra
cluster with a replication factor of 3. Couple of days ago we noticed
that Cassandra sometimes returns the wrong data. Not corrupted data,
but data for a different key than the one being asked for. This error
appears to be random
-----
> From: "Jianing Hu"
> Sent: Saturday, March 27, 2010 12:07pm
> To: user@cassandra.apache.org
> Subject: Re: FW: Re: Is ReplicationFactor (eventually) guaranteed?
>
> Here's the conf file, with comments removed. Thanks a lot for your hel
> you deleted it. Repair depends on the replication factor being greater than 1.
>
> -Original Message-
> From: "Jianing Hu"
> Sent: Friday, March 26, 2010 9:33pm
> To: user@cassandra.apache.org
> Subject: Re: Is ReplicationFactor (eventually) guaranteed?
&
This is 0.5.1 BTW.
Thanks,
- Jianing
On Fri, Mar 26, 2010 at 6:12 PM, Rob Coli wrote:
> On 3/26/10 5:57 PM, Jianing Hu wrote:
>>
>> In a cluster with ReplicationFactor> 1, if one server goes down, will
>> new replicas be created on other servers to satisfy the set
In a cluster with ReplicationFactor > 1, if one server goes down, will
new replicas be created on other servers to satisfy the set
ReplicationFactor? I ran some tests that seem to suggest no new
replicas were created. Is that the expected behavior? If so, is there
a way to guarantee that any data a
12 matches
Mail list logo
