You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by csharpplusproject <cs...@gmail.com> on 2011/04/17 15:17:26 UTC
Cassandra 0.7.4 Bug?
Often, I see the following behavior:
(1) Cassandra works, all nodes are up etc
(2) a 'move' operation is being run on one of the nodes
(3) following this 'move' operation, even after a couple of hours / days
where it is obvious the operation has ended, the node which had 'moved'
remains with a status of ?
perhaps it's a bug?
___________________________________________________________________________________
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
192.168.0.5 ring
Address Status State Load Owns
Token
127605887595351923798765477786913079296
192.168.0.253 Up Normal 88.66 MB 25.00%
0
192.168.0.4 Up Normal 558.2 MB 50.00%
85070591730234615865843651857942052863
192.168.0.5 Up Normal 71.03 MB 16.67%
113427455640312821154458202477256070485
192.168.0.6 Up Normal 44.71 MB 8.33%
127605887595351923798765477786913079296
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
192.168.0.4 move 92535295865117307932921825928971026432
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
192.168.0.5 ring
Address Status State Load Owns
Token
127605887595351923798765477786913079296
192.168.0.253 Up Normal 171.17 MB 25.00%
0
192.168.0.4 ? Normal 212.11 MB 54.39%
92535295865117307932921825928971026432
192.168.0.5 Up Normal 263.91 MB 12.28%
113427455640312821154458202477256070485
192.168.0.6 Up Normal 26.21 MB 8.33%
127605887595351923798765477786913079296
Re: CQL DELETE statement
Posted by Jonathan Ellis <jb...@gmail.com>.
Transport isn't the problem.
On Mon, Apr 18, 2011 at 6:21 PM, Courtney Robinson <sa...@live.co.uk> wrote:
> Cool... Okay, the plan is to eventually not use thrift underneath, for the
> CQL stuff right?
> Once this is done and the new transport is in place, or evening while
> designing the new transport,
> is this not something that's worth looking into again? I think it'd be a
> nice feature.
>
> -----Original Message----- From: Jonathan Ellis
> Sent: Monday, April 18, 2011 3:24 AM
> To: user@cassandra.apache.org
> Cc: Tyler Hobbs
> Subject: Re: CQL DELETE statement
>
> Very old. https://issues.apache.org/jira/browse/CASSANDRA-494
>
> On Sun, Apr 17, 2011 at 7:49 PM, Tyler Hobbs <ty...@datastax.com> wrote:
>>
>> You are correct, but this is also a limitation with the Thrift API -- it's
>> not CQL specific. It turns out that deleting a slice of columns is
>> difficult. There's an old JIRA ticket somewhere that describes the
>> issues.
>>
>> On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson <sa...@live.co.uk>
>> wrote:
>>>
>>> Looking at the CQL spec, it doesn’t seem to be possible to delete a range
>>> of columns for a given key without specifying the individual columns to
>>> be
>>> removed, for e.g.
>>> DELETE col1 .. col20 from CF WHERE KEY=<key|(key1,key2)>
>>> Am I correct in thinking so or have I missed that somewhere?
>>>
>>
>>
>> --
>> Tyler Hobbs
>> Software Engineer, DataStax
>> Maintainer of the pycassa Cassandra Python client library
>>
>>
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
CQL transport (was: CQL DELETE statement)
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Tue, 19 Apr 2011 00:21:44 +0100 Courtney Robinson <sa...@live.co.uk> wrote:
CR> Cool... Okay, the plan is to eventually not use thrift underneath,
CR> for the CQL stuff right? Once this is done and the new transport is
CR> in place, or evening while designing the new transport, is this not
CR> something that's worth looking into again? I think it'd be a nice
CR> feature.
I'm assuming your question was tangential and not in the sense that
"fixing the transport will fix the reported issue."
There's https://issues.apache.org/jira/browse/CASSANDRA-2478 for a
custom non-Thrift protocol. Most of the Cassandra developers feel
HTTP+JSON or XML is inadequate for this purpose; while this may be true
for some cases, it's also true that for many of the end users HTTP+JSON
or XML is easier to support and use from a client. So I hope eventually
HTTP as the transport and JSON or XML as the serialization format are at
least an option.
Ted
Re: CQL DELETE statement
Posted by Courtney Robinson <sa...@live.co.uk>.
Cool... Okay, the plan is to eventually not use thrift underneath, for the
CQL stuff right?
Once this is done and the new transport is in place, or evening while
designing the new transport,
is this not something that's worth looking into again? I think it'd be a
nice feature.
-----Original Message-----
From: Jonathan Ellis
Sent: Monday, April 18, 2011 3:24 AM
To: user@cassandra.apache.org
Cc: Tyler Hobbs
Subject: Re: CQL DELETE statement
Very old. https://issues.apache.org/jira/browse/CASSANDRA-494
On Sun, Apr 17, 2011 at 7:49 PM, Tyler Hobbs <ty...@datastax.com> wrote:
> You are correct, but this is also a limitation with the Thrift API -- it's
> not CQL specific. It turns out that deleting a slice of columns is
> difficult. There's an old JIRA ticket somewhere that describes the
> issues.
>
> On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson <sa...@live.co.uk>
> wrote:
>>
>> Looking at the CQL spec, it doesn’t seem to be possible to delete a range
>> of columns for a given key without specifying the individual columns to
>> be
>> removed, for e.g.
>> DELETE col1 .. col20 from CF WHERE KEY=<key|(key1,key2)>
>> Am I correct in thinking so or have I missed that somewhere?
>>
>
>
> --
> Tyler Hobbs
> Software Engineer, DataStax
> Maintainer of the pycassa Cassandra Python client library
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL DELETE statement
Posted by Jonathan Ellis <jb...@gmail.com>.
Very old. https://issues.apache.org/jira/browse/CASSANDRA-494
On Sun, Apr 17, 2011 at 7:49 PM, Tyler Hobbs <ty...@datastax.com> wrote:
> You are correct, but this is also a limitation with the Thrift API -- it's
> not CQL specific. It turns out that deleting a slice of columns is
> difficult. There's an old JIRA ticket somewhere that describes the issues.
>
> On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson <sa...@live.co.uk> wrote:
>>
>> Looking at the CQL spec, it doesn’t seem to be possible to delete a range
>> of columns for a given key without specifying the individual columns to be
>> removed, for e.g.
>> DELETE col1 .. col20 from CF WHERE KEY=<key|(key1,key2)>
>> Am I correct in thinking so or have I missed that somewhere?
>>
>
>
> --
> Tyler Hobbs
> Software Engineer, DataStax
> Maintainer of the pycassa Cassandra Python client library
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL DELETE statement
Posted by Tyler Hobbs <ty...@datastax.com>.
You are correct, but this is also a limitation with the Thrift API -- it's
not CQL specific. It turns out that deleting a slice of columns is
difficult. There's an old JIRA ticket somewhere that describes the issues.
On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson <sa...@live.co.uk> wrote:
> Looking at the CQL spec, it doesn’t seem to be possible to delete a
> range of columns for a given key without specifying the individual columns
> to be removed, for e.g.
> DELETE col1 .. col20 from CF WHERE KEY=<key|(key1,key2)>
> Am I correct in thinking so or have I missed that somewhere?
>
>
--
Tyler Hobbs
Software Engineer, DataStax <http://datastax.com/>
Maintainer of the pycassa <http://github.com/pycassa/pycassa> Cassandra
Python client library
CQL DELETE statement
Posted by Courtney Robinson <sa...@live.co.uk>.
Looking at the CQL spec, it doesn’t seem to be possible to delete a range of columns for a given key without specifying the individual columns to be removed, for e.g.
DELETE col1 .. col20 from CF WHERE KEY=<key|(key1,key2)>
Am I correct in thinking so or have I missed that somewhere?
Re: Cassandra 0.7.4 Bug?
Posted by Alexis Lê-Quôc <al...@datadoghq.com>.
I've had a related issue in the past:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Gossip-mysteries-0-7-4-on-EC2-td6217786.html
No resolution so far. By restarting everything the problem went away.
On Sun, Apr 17, 2011 at 3:23 PM, csharpplusproject
<cs...@gmail.com> wrote:
> Shimi,
>
> Chag Sameach. Yes, I know that a restart solves this, yet, I think this is
> something that must be resolved as a result of 'nodetool move'.
>
> Shalom.
>
> -----Original Message-----
> From: shimi <sh...@gmail.com>
> Reply-to: user@cassandra.apache.org
> To: user@cassandra.apache.org
> Subject: Re: Cassandra 0.7.4 Bug?
> Date: Sun, 17 Apr 2011 22:17:59 +0300
>
> I had the same thing.
> Node restart should solve it.
>
> Shimi
>
>
> On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu <di...@gmail.com> wrote:
>
> +1.
>
> I also met this problem several days before, and I haven't got a solution
> yet...
>
>
> On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject
> <cs...@gmail.com> wrote:
>
> Often, I see the following behavior:
>
> (1) Cassandra works, all nodes are up etc
>
> (2) a 'move' operation is being run on one of the nodes
>
> (3) following this 'move' operation, even after a couple of hours / days
> where it is obvious the operation has ended, the node which had 'moved'
> remains with a status of ?
>
> perhaps it's a bug?
>
> ___________________________________________________________________________________
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.5 ring
> Address Status State Load Owns
> Token
>
> 127605887595351923798765477786913079296
> 192.168.0.253 Up Normal 88.66 MB 25.00%
> 0
> 192.168.0.4 Up Normal 558.2 MB 50.00%
> 85070591730234615865843651857942052863
> 192.168.0.5 Up Normal 71.03 MB 16.67%
> 113427455640312821154458202477256070485
> 192.168.0.6 Up Normal 44.71 MB 8.33%
> 127605887595351923798765477786913079296
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.4 move 92535295865117307932921825928971026432
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.5 ring
> Address Status State Load Owns
> Token
>
> 127605887595351923798765477786913079296
> 192.168.0.253 Up Normal 171.17 MB 25.00%
> 0
> 192.168.0.4 ? Normal 212.11 MB 54.39%
> 92535295865117307932921825928971026432
> 192.168.0.5 Up Normal 263.91 MB 12.28%
> 113427455640312821154458202477256070485
> 192.168.0.6 Up Normal 26.21 MB 8.33%
> 127605887595351923798765477786913079296
>
>
>
> --
> Dikang Gu
>
> 0086 - 18611140205
>
>
>
>
>
--
Alexis Lê-Quôc (@alq) | Datadog, Inc. | http://datadoghq.com
Re: Cassandra 0.7.4 Bug?
Posted by csharpplusproject <cs...@gmail.com>.
Shimi,
Chag Sameach. Yes, I know that a restart solves this, yet, I think this
is something that must be resolved as a result of 'nodetool move'.
Shalom.
-----Original Message-----
From: shimi <sh...@gmail.com>
Reply-to: user@cassandra.apache.org
To: user@cassandra.apache.org
Subject: Re: Cassandra 0.7.4 Bug?
Date: Sun, 17 Apr 2011 22:17:59 +0300
I had the same thing.
Node restart should solve it.
Shimi
On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu <di...@gmail.com> wrote:
+1.
I also met this problem several days before, and I haven't got a
solution yet...
On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject
<cs...@gmail.com> wrote:
Often, I see the following behavior:
(1) Cassandra works, all nodes are up etc
(2) a 'move' operation is being run on one of the nodes
(3) following this 'move' operation, even after a couple
of hours / days where it is obvious the operation has
ended, the node which had 'moved' remains with a status
of ?
perhaps it's a bug?
___________________________________________________________________________________
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$
bin/nodetool -host 192.168.0.5 ring
Address Status State Load Owns
Token
127605887595351923798765477786913079296
192.168.0.253 Up Normal 88.66 MB 25.00%
0
192.168.0.4 Up Normal 558.2 MB 50.00%
85070591730234615865843651857942052863
192.168.0.5 Up Normal 71.03 MB 16.67%
113427455640312821154458202477256070485
192.168.0.6 Up Normal 44.71 MB 8.33%
127605887595351923798765477786913079296
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$
bin/nodetool -host 192.168.0.4 move
92535295865117307932921825928971026432
shalom@host:/opt/cassandra/apache-cassandra-0.7.4$
bin/nodetool -host 192.168.0.5 ring
Address Status State Load Owns
Token
127605887595351923798765477786913079296
192.168.0.253 Up Normal 171.17 MB 25.00%
0
192.168.0.4 ? Normal 212.11 MB 54.39%
92535295865117307932921825928971026432
192.168.0.5 Up Normal 263.91 MB 12.28%
113427455640312821154458202477256070485
192.168.0.6 Up Normal 26.21 MB 8.33%
127605887595351923798765477786913079296
--
Dikang Gu
0086 - 18611140205
Re: Cassandra 0.7.4 Bug?
Posted by shimi <sh...@gmail.com>.
I had the same thing.
Node restart should solve it.
Shimi
On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu <di...@gmail.com> wrote:
> +1.
>
> I also met this problem several days before, and I haven't got a solution
> yet...
>
>
> On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject <
> csharpplusproject@gmail.com> wrote:
>
>> Often, I see the following behavior:
>>
>> (1) Cassandra works, all nodes are up etc
>>
>> (2) a 'move' operation is being run on one of the nodes
>>
>> (3) following this 'move' operation, even after a couple of hours / days
>> where it is obvious the operation has ended, the node which had 'moved'
>> remains with a status of *?*
>>
>> perhaps it's a bug?
>>
>>
>> ___________________________________________________________________________________
>>
>> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
>> 192.168.0.5 ring
>> Address Status State Load Owns
>> Token
>>
>> 127605887595351923798765477786913079296
>> 192.168.0.253 Up Normal 88.66 MB 25.00%
>> 0
>> 192.168.0.4 Up Normal 558.2 MB 50.00%
>> 85070591730234615865843651857942052863
>> 192.168.0.5 Up Normal 71.03 MB 16.67%
>> 113427455640312821154458202477256070485
>> 192.168.0.6 Up Normal 44.71 MB 8.33%
>> 127605887595351923798765477786913079296
>>
>> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
>> 192.168.0.4 move 92535295865117307932921825928971026432
>>
>> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
>> 192.168.0.5 ring
>> Address Status State Load Owns
>> Token
>>
>> 127605887595351923798765477786913079296
>> 192.168.0.253 Up Normal 171.17 MB 25.00%
>> 0
>> 192.168.0.4 *?* Normal 212.11 MB 54.39%
>> 92535295865117307932921825928971026432
>> 192.168.0.5 Up Normal 263.91 MB 12.28%
>> 113427455640312821154458202477256070485
>> 192.168.0.6 Up Normal 26.21 MB 8.33%
>> 127605887595351923798765477786913079296
>>
>
>
>
> --
> Dikang Gu
>
> 0086 - 18611140205
>
>
Re: Cassandra 0.7.4 Bug?
Posted by Dikang Gu <di...@gmail.com>.
+1.
I also met this problem several days before, and I haven't got a solution
yet...
On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject <
csharpplusproject@gmail.com> wrote:
> Often, I see the following behavior:
>
> (1) Cassandra works, all nodes are up etc
>
> (2) a 'move' operation is being run on one of the nodes
>
> (3) following this 'move' operation, even after a couple of hours / days
> where it is obvious the operation has ended, the node which had 'moved'
> remains with a status of *?*
>
> perhaps it's a bug?
>
>
> ___________________________________________________________________________________
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.5 ring
> Address Status State Load Owns
> Token
>
> 127605887595351923798765477786913079296
> 192.168.0.253 Up Normal 88.66 MB 25.00%
> 0
> 192.168.0.4 Up Normal 558.2 MB 50.00%
> 85070591730234615865843651857942052863
> 192.168.0.5 Up Normal 71.03 MB 16.67%
> 113427455640312821154458202477256070485
> 192.168.0.6 Up Normal 44.71 MB 8.33%
> 127605887595351923798765477786913079296
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.4 move 92535295865117307932921825928971026432
>
> shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host
> 192.168.0.5 ring
> Address Status State Load Owns
> Token
>
> 127605887595351923798765477786913079296
> 192.168.0.253 Up Normal 171.17 MB 25.00%
> 0
> 192.168.0.4 *?* Normal 212.11 MB 54.39%
> 92535295865117307932921825928971026432
> 192.168.0.5 Up Normal 263.91 MB 12.28%
> 113427455640312821154458202477256070485
> 192.168.0.6 Up Normal 26.21 MB 8.33%
> 127605887595351923798765477786913079296
>
--
Dikang Gu
0086 - 18611140205