On Wed, Oct 24, 2012 at 2:32 PM, aaron morton wrote:
> I don't see errors in the logs, but I do see
> a lot of dropped mutations and reads. Any correlation?
>
> Yes.
> The dropped messages mean the server is overloaded.
>
> +1 . Been there..overloaded system normally produce frequent dropped
muta
Hi!
I tried again, I see the scrub action in cassandra logs
INFO [CompactionExecutor:4029] 2012-10-24 10:36:54,108
CompactionManager.java (line 476) Scrubbing
SSTableReader(path='/raid0/cassandra/data/tok/tk_usus_user-hc-339-Data.db')
INFO [CompactionExecutor:4029] 2012-10-24 10:36:54,184
Compact
Keep in mind, returning the older version is usually fine. Just imagine
if your user clicked write 1 ms before, then the new version might be
returned. If he gets the older version and refreshes the page, he gets
the newer version. Same with an automated program as wellÅ .in general it
is okay to
On Sun, Oct 21, 2012 at 6:44 PM, aaron morton wrote:
> I *think* this may be ghost rows which have not being compacted.
You would be correct in the case of 1.0.8:
https://issues.apache.org/jira/browse/CASSANDRA-3955
-Brandon
Is there a walk around other than upgrade?
Thanks,
*Tamar Fraenkel *
Senior Software Engineer, TOK Media
[image: Inline image 1]
ta...@tok-media.com
Tel: +972 2 6409736
Mob: +972 54 8356490
Fax: +972 2 5612956
On Wed, Oct 24, 2012 at 1:56 PM, Brandon Williams wrote:
> On Sun, Oct 21,
Hiller, Dean wrote
> in general it is okay to get the older or newer value. If you are reading
> 2 rows however instead of one, that may change.
This is certainly interesting, as it could mean that the user could see a
value that never met the required consistency. For instance with 3 replicas
a
That worked perfectly, inserting another row after the first compaction,
then flushing and compacting again triggered the empty rows to be removed.
Thanks for your help and for clarifying the "gcBefore" point Aaron.
Stephen
On Tue, Oct 23, 2012 at 4:47 PM, aaron morton wrote:
> In the first exam
The user will meet the required consistency unless you encounter some kind
of bug in cassandra. You will either get the older value or the newer
value. If you read quorum, and maybe a write CL=1 just happened, you may
get the older or new value depending on if the node that received the
write was
And we don't send read request to all of the three replicas (R1, R2, R3) if
CL=QUOROM; just 2 of them depending on proximity
On Wed, Oct 24, 2012 at 10:20 PM, Hiller, Dean wrote:
> The user will meet the required consistency unless you encounter some kind
> of bug in cassandra. You will either
I guess one more thing is I completely ignore your second write mainly because
I assume it comes after we already read so your let's say you current state is
node1 = val1 node2 = val1 node3 = val1
You do a write quorom of val=2 which is IN the middle!!!
node1 = val1 node2 = val2 node3 = val1 (
oh, it would clarity a lot if you go to read the source code; the method is
o.a.c.service.StorageProxy.fetchRows if I remember it correctly
On Wed, Oct 24, 2012 at 10:26 PM, Manu Zhang wrote:
> And we don't send read request to all of the three replicas (R1, R2, R3)
> if CL=QUOROM; just 2 of them
Hiller, Dean wrote
> I guess one more thing is I completely ignore your second write mainly
> because I assume it comes after we already read so your let's say you
> current state is
>
> node1 = val1 node2 = val1 node3 = val1
>
> You do a write quorom of val=2 which is IN the middle!!!
>
> node1
>Thanks Zhang. But, this again seems a little strange thing to do, since
>one
>(say R2) of the 2 close replicas (say R1,R2) might be down, resulting in a
>read failure while there are still enough number of replicas (R1 and R3)
>live to satisfy a read.
He means in the case where all 3 nodes are l
Hello all,
I'm playing around with using the get_paged_slice thrift call, and I noticed
that it always was returning to me everything in the row--there's no mechanism
for specifying a SlicePredicate. Was that intentional? If so, is there a
different way that I can limit what I get back? I'd lik
And if you want a competitive edge, use it, tune it, take full advantage of the
better version (7) and DON'T share. See the problem with not assigning this as
a first class task for ASF team?
Sent from my iPad
On Oct 23, 2012, at 11:12 PM, Eric Evans wrote:
> On Tue, Oct 16, 2012 at 7:54 PM,
On Wed, Oct 24, 2012 at 11:41 AM, Voodoo wrote:
> And if you want a competitive edge, use it, tune it, take full advantage of
> the better version (7) and DON'T share. See the problem with not assigning
> this as a first class task for ASF team?
Umm, no? Care to explain?
> On Oct 23, 2012, at
We have been using cassandra and java7 for months. No problems. A key
concept of java is portable binaries. There are sometimes wrinkles with
upgrades. If you hit one undo the upgrade and restart.
On Tuesday, October 23, 2012, Eric Evans wrote:
> On Tue, Oct 16, 2012 at 7:54 PM, Rob Coli wrote:
On Mon, Oct 22, 2012 at 8:38 AM, Bryan Talbot wrote:
> The nodes with the most data used the most memory. All nodes are affected
> eventually not just one. The GC was on-going even when the nodes were not
> compacting or running a heavy application load -- even when the main app was
> paused con
I'm testing various scenarios in a multi data center configuration. The setup
is 10 Cassandra 1.1.5 nodes configured into two data centers, 5 nodes in each
DC (RF DC1:3,DC2:3, write consistency LOCAL_QUORUM). I have a synthetic random
data generator that I can run, and each run adds roughly 1Gi
On Wed, Oct 24, 2012 at 2:38 PM, Rob Coli wrote:
> On Mon, Oct 22, 2012 at 8:38 AM, Bryan Talbot
> wrote:
> > The nodes with the most data used the most memory. All nodes are
> affected
> > eventually not just one. The GC was on-going even when the nodes were
> not
> > compacting or running a
Can you try restarting the node ? That would reload the CF Meta data and reset
the compaction settings.
Sorry that's not very helpful but it's all I can think of for now.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 24/10/2012, at 11:4
Thanks.
I thought it had been addressed so before but couldn't find the ticket.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 25/10/2012, at 12:56 AM, Brandon Williams wrote:
> On Sun, Oct 21, 2012 at 6:44 PM, aaron morton wrote:
>> I
Hints store the columns, row key, KS name and CF id(s) for each mutation to
each node. Where an executed mutation will store the most recent columns
collated with others under the same row key. So depending on the type of
mutation hints will take up more space.
The worse case would be lots of
Are you using openJDK or Oracle JDK? I know java7 should be based on
openJDK since 7, but still not sure.
On 25 October 2012 05:42, Edward Capriolo wrote:
> We have been using cassandra and java7 for months. No problems. A key
> concept of java is portable binaries. There are sometimes wrinkles
FWIW, we're using openjdk7 on most of our clusters. For those where we
are still on openjdk6, it's not because of an issue - just haven't
gotten to rolling out the upgrade yet.
We haven't had any issues that I recall with upgrading the JDK.
--
/ Peter Schuller (@scode, http://worldmodscode.wordp
25 matches
Mail list logo