[jira] [Updated] (CASSANDRA-6212) TimestampType doesn't support pre-epoch long
[ https://issues.apache.org/jira/browse/CASSANDRA-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6212: --- Attachment: cassandra-2.0-6212.patch Changed the regexp to accept a leading "-" > TimestampType doesn't support pre-epoch long > > > Key: CASSANDRA-6212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6212 > Project: Cassandra > Issue Type: Bug > Components: API, Core >Reporter: Simon Hopkin >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 2.0.2 > > Attachments: cassandra-2.0-6212.patch > > > org.apache.cassandra.db.marshal.TimestampType.dateStringToTimestamp() > contains a regular expression that checks to see if the String argument > contains a number. If so it parses it as a long timestamp. However > pre-epoch timestamps are negative and the code doesn't account for this so it > tries to parse it as a formatted Date. A tweak to the regular expression in > TimestampType.dateStringToTimestamp() would solve this issue. > I could use formatted date strings instead, but the TimestampType date parser > uses ISO8601 patterns which would cause the timestamp to be rounded to the > nearest second. > Currently I get the following exception message: > unable to coerce '-8640' to a formatted date (long) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6196) Add compaction, compression to cqlsh tab completion for CREATE TABLE
[ https://issues.apache.org/jira/browse/CASSANDRA-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6196: - Reproduced In: 2.0.1, 1.2.10 Fix Version/s: 1.2.12 > Add compaction, compression to cqlsh tab completion for CREATE TABLE > > > Key: CASSANDRA-6196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6196 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jonathan Ellis >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 1.2.12, 2.0.2 > > Attachments: cassandra-2.0-6196.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6196) Add compaction, compression to cqlsh tab completion for CREATE TABLE
[ https://issues.apache.org/jira/browse/CASSANDRA-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800369#comment-13800369 ] Aleksey Yeschenko commented on CASSANDRA-6196: -- [~mishail] The issue is present in 1.2, too, so the patch should be 1.2-based. Also, the patch does not fix auto completion for ALTER TABLE. Could you please handle that as well? > Add compaction, compression to cqlsh tab completion for CREATE TABLE > > > Key: CASSANDRA-6196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6196 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jonathan Ellis >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 1.2.12, 2.0.2 > > Attachments: cassandra-2.0-6196.patch > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6179) "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
[
https://issues.apache.org/jira/browse/CASSANDRA-6179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800359#comment-13800359
]
Mikhail Stepura commented on CASSANDRA-6179:
Can it be due to the difference between "Live" and "Total" space used?
[~jre] Could you please attach the output of {{nodetool cfstats}} ?
> "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
> -
>
> Key: CASSANDRA-6179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6179
> Project: Cassandra
> Issue Type: Bug
> Environment: JBOD layouts
>Reporter: J. Ryan Earl
>Assignee: Mikhail Stepura
>
> We recently noticed that the storage capacity on Cassandra nodes using JBOD
> layout was returning what looks close to the average data volume size,
> instead of the sum of all JBOD data volumes. It's not exactly an average and
> I haven't had time to dig into the code to see what it's really doing, it's
> like some sort of sample of the JBOD volumes sizes.
> So looking at the JBOD volumes we see:
> {noformat}
> [jre@cassandra2 ~]$ df -h
> FilesystemSize Used Avail Use% Mounted on
> [...]
> /dev/sdc1 1.1T 9.4G 1.1T 1% /data/1
> /dev/sdd1 1.1T 9.2G 1.1T 1% /data/2
> /dev/sde1 1.1T 11G 1.1T 1% /data/3
> /dev/sdf1 1.1T 11G 1.1T 1% /data/4
> /dev/sdg1 1.1T 9.2G 1.1T 1% /data/5
> /dev/sdh1 1.1T 11G 1.1T 1% /data/6
> /dev/sdi1 1.1T 9.8G 1.1T 1% /data/7
> {noformat}
> Looking at 'nodetool info' we see:
> {noformat}
> [jre@cassandra2 ~]$ nodetool info
> Token: (invoke with -T/--tokens to see all 256 tokens)
> ID : 631f0be3-ce52-4eb9-b48b-069fbfdf0a97
> Gossip active: true
> Thrift active: true
> Native Transport active: true
> Load : 10.57 GB
> {noformat}
> So there are 7 disks in a JBOD configuration in this example, the sum should
> be closer to 70G for each node. Maybe we're misinterpreting what this value
> should be, but things like OpsCenter appear to use this "load" value as the
> size of data on the local node, which I expect to be the sum of JBOD volumes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6211) NPE in system.log
[
https://issues.apache.org/jira/browse/CASSANDRA-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800349#comment-13800349
]
Mikhail Mazursky commented on CASSANDRA-6211:
-
Also, I can add that these exceptions happen periodically in "chunks" of ~20.
> NPE in system.log
> -
>
> Key: CASSANDRA-6211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6211
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> Linux hostname 2.6.32-279.el6.x86_64 #1 SMP Thu Jun 21 15:00:18 EDT 2012
> x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Mikhail Mazursky
> Labels: npe, nullpointerexception
>
> I wrote a stresstest to test C* and my code that uses CAS heavily. I see
> strange exception messages in logs:
> {noformat}
> ERROR [MutationStage:320] 2013-10-17 13:59:10,710 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:320,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:328] 2013-10-17 13:59:10,718 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:328,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:327] 2013-10-17 13:59:10,732 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:327,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:325] 2013-10-17 13:59:10,750 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:325,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:326] 2013-10-17 13:59:10,762 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:326,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:330] 2013-10-17 13:59:10,768 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:330,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:331] 2013-10-17 13:59:10,775 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:331,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:334] 2013-10-17 13:59:10,789 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:334,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:329] 2013-10-17 13:59:10,803 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:329,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:335] 2013-10-17 13:59:10,812 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:335,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:333] 2013-10-17 13:59:10,826 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:333,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:332] 2013-10-17 13:59:10,834 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:332,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:337] 2013-10-17 13:59:10,842 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:337,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:336] 2013-10-17 13:59:10,859 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:336,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:338] 2013-10-17 13:59:10,870 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:338,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:339] 2013-10-17 13:59:10,884 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:339,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:341] 2013-10-17 13:59:10,894 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:341,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:340] 2013-10-17 13:59:10,910 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:340,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:344] 2013-10-17 13:59:10,920 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:344,5,main]
> java.lang.NullPointerException
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6211) NPE in system.log
[
https://issues.apache.org/jira/browse/CASSANDRA-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800348#comment-13800348
]
Mikhail Mazursky commented on CASSANDRA-6211:
-
No, nothing special. Just a fresh deployment. By the way, client got no
exceptions. All requests succeded and data was readable after that. So probably
these exceptions are happening asynchronously to the request processing.
> NPE in system.log
> -
>
> Key: CASSANDRA-6211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6211
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> Linux hostname 2.6.32-279.el6.x86_64 #1 SMP Thu Jun 21 15:00:18 EDT 2012
> x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Mikhail Mazursky
> Labels: npe, nullpointerexception
>
> I wrote a stresstest to test C* and my code that uses CAS heavily. I see
> strange exception messages in logs:
> {noformat}
> ERROR [MutationStage:320] 2013-10-17 13:59:10,710 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:320,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:328] 2013-10-17 13:59:10,718 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:328,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:327] 2013-10-17 13:59:10,732 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:327,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:325] 2013-10-17 13:59:10,750 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:325,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:326] 2013-10-17 13:59:10,762 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:326,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:330] 2013-10-17 13:59:10,768 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:330,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:331] 2013-10-17 13:59:10,775 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:331,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:334] 2013-10-17 13:59:10,789 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:334,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:329] 2013-10-17 13:59:10,803 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:329,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:335] 2013-10-17 13:59:10,812 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:335,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:333] 2013-10-17 13:59:10,826 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:333,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:332] 2013-10-17 13:59:10,834 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:332,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:337] 2013-10-17 13:59:10,842 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:337,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:336] 2013-10-17 13:59:10,859 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:336,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:338] 2013-10-17 13:59:10,870 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:338,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:339] 2013-10-17 13:59:10,884 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:339,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:341] 2013-10-17 13:59:10,894 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:341,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:340] 2013-10-17 13:59:10,910 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:340,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:344] 2013-10-17 13:59:10,920 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:344,5,main]
> java.lang.NullPointerException
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-5911) Commit logs are not removed after nodetool flush or nodetool drain
[
https://issues.apache.org/jira/browse/CASSANDRA-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800345#comment-13800345
]
Jonathan Ellis commented on CASSANDRA-5911:
---
This is also part of why people see mutations from dropped CFs replay after
restart. So I think it's worth it to make this change in 2.0.x (but not
1.2.y).
So +1 from me in general, however I think we need to be extra aggressive in the
drop scenario and *require* switching to a new segment. Ambivalent leaning to
-0 as to whether we want to retain the "switch to next segment if we have an
extra one available" logic for every flush; we still have the confusing
behavior, just less often. Maybe improving logging clarity is all we need
there.
> Commit logs are not removed after nodetool flush or nodetool drain
> --
>
> Key: CASSANDRA-5911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5911
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: J.B. Langston
>Assignee: Vijay
>Priority: Minor
> Fix For: 2.0.2
>
> Attachments: 0001-CASSANDRA-5911.patch,
> 6528_140171_knwmuqxe9bjv5re_system.log
>
>
> Commit logs are not removed after nodetool flush or nodetool drain. This can
> lead to unnecessary commit log replay during startup. I've reproduced this
> on Apache Cassandra 1.2.8. Usually this isn't much of an issue but on a
> Solr-indexed column family in DSE, each replayed mutation has to be reindexed
> which can make startup take a long time (on the order of 20-30 min).
> Reproduction follows:
> {code}
> jblangston:bin jblangston$ ./cassandra > /dev/null
> jblangston:bin jblangston$ ../tools/bin/cassandra-stress -n 2000 >
> /dev/null
> jblangston:bin jblangston$ du -h ../commitlog
> 576M ../commitlog
> jblangston:bin jblangston$ nodetool flush
> jblangston:bin jblangston$ du -h ../commitlog
> 576M ../commitlog
> jblangston:bin jblangston$ nodetool drain
> jblangston:bin jblangston$ du -h ../commitlog
> 576M ../commitlog
> jblangston:bin jblangston$ pkill java
> jblangston:bin jblangston$ du -h ../commitlog
> 576M ../commitlog
> jblangston:bin jblangston$ ./cassandra -f | grep Replaying
> INFO 10:03:42,915 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566773.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566774.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566775.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566776.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566777.log,
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566778.log
> INFO 10:03:42,922 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log
> INFO 10:03:43,907 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log
> INFO 10:03:43,907 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log
> INFO 10:03:43,907 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log
> INFO 10:03:43,908 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log
> INFO 10:03:43,908 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log
> INFO 10:03:43,908 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log
> INFO 10:03:43,909 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log
> INFO 10:03:43,909 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log
> INFO 10:03:43,909 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log
> INFO 10:03:43,910 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log
> INFO 10:03:43,910 Replaying
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log
> INFO 10:03:43,911 Replaying
>
[jira] [Commented] (CASSANDRA-6168) nodetool status reports 05 ownership when no keyspace is spacified
[
https://issues.apache.org/jira/browse/CASSANDRA-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800342#comment-13800342
]
Brandon Williams commented on CASSANDRA-6168:
-
Well, we do issue a warning when no keyspace is specified.
> nodetool status reports 05 ownership when no keyspace is spacified
> --
>
> Key: CASSANDRA-6168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6168
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Patricio Echague
>Priority: Minor
>
> Seen in 1.2.10.
> Apologies if this is expected behavior. Nodetool status reports 0% ownership
> unless I add a keyspace name.
> nodetool help docs says:
> ..." status - Print cluster information (state, load, IDs,
> ...)"...
> output without keyspace name
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
>Rack
> UN 10.x.x.146 81.96 GB 256 0.0%
> a70c59b3-a667-4d76-ba5b-ba849ad672da r1
> UN 10.x.x.63 95.32 GB 256 0.0%
> f8cb7b10-4ebe-484a-a1c0-6cb2d053901b r1
> UN 10.x.x.184 89.54 GB 256 0.1%
> cd86c420-55e2-4d99-8ed9-d9ee8d6a9d9c r1
> UN 10.x.x.190 79.68 GB 256 0.0%
> 544c3906-bc02-400d-9fd2-1e39ecadd6ff r1
> UN 10.x.x.168 93.44 GB 256 0.7%
> 33be316f-1276-475d-90cf-2667950d3a2c r1
> UN 10.x.x.132 84.4 GB256 0.0%
> b327d9f1-cab0-4583-8e5e-95c50b4074fd r1
> Datacenter: DCOFFLINE
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
>Rack
> UN 10.x.x.62 56.09 GB 256 32.4%
> c8994d27-767b-431f-bdc2-9196eeeb6f44 r1
> UN 10.x.x.131 60.11 GB 256 32.8%
> 0b9d3314-039e-4f88-8ba6-d0f2885d9a30 r1
> UN 10.x.x.167 56.45 GB 256 34.0%
> ba76f4fe-4250-4839-a37d-c1a7c24e585d r1
> {code}
> and with keyspace. Example: nodetool status MYKSPS
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 10.x.x.184 89.51 GB 256 50.0%
> cd86c420-55e2-4d99-8ed9-d9ee8d6a9d9c r1
> UN 10.x.x.146 81.96 GB 256 50.0%
> a70c59b3-a667-4d76-ba5b-ba849ad672da r1
> UN 10.x.x.168 93.44 GB 256 50.0%
> 33be316f-1276-475d-90cf-2667950d3a2c r1
> UN 10.x.x.63 95.32 GB 256 50.0%
> f8cb7b10-4ebe-484a-a1c0-6cb2d053901b r1
> UN 10.x.x.190 79.68 GB 256 50.0%
> 544c3906-bc02-400d-9fd2-1e39ecadd6ff r1
> UN 10.x.x.132 84.4 GB256 50.0%
> b327d9f1-cab0-4583-8e5e-95c50b4074fd r1
> Datacenter: DCOFFLINE
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 10.x.x.131 60.11 GB 256 32.8%
> 0b9d3314-039e-4f88-8ba6-d0f2885d9a30 r1
> UN 10.x.x.167 56.45 GB 256 34.7%
> ba76f4fe-4250-4839-a37d-c1a7c24e585d r1
> UN 10.x.x.62 56.09 GB 256 32.5%
> c8994d27-767b-431f-bdc2-9196eeeb6f44 r1
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6167) Add end-slice termination predicate
[
https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6167:
--
Labels: ponies (was: )
> Add end-slice termination predicate
> ---
>
> Key: CASSANDRA-6167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
>Reporter: Tupshin Harper
>Priority: Minor
> Labels: ponies
>
> When doing performing storage-engine slices, it would sometimes be beneficial
> to have the slice terminate for other reasons other than number of columns or
> min/max cell name.
> Since we are able to look at the contents of each cell as we read it, this is
> potentially doable with very little overhead.
> Probably more challenging than the storage-engine implementation itself, is
> to come up with appropriate CQL syntax (Thrift, should we decide to support
> it, would be trivial).
> Two possibilities ar
> 1) special where function:
> SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND
> partition_predicate({predicate})
> or a bigger language change, but i think one I prefer. more like:
> 2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event
> {predicate}
> Neither feels perfect, but I do like the fact that the second one at least
> clearly states what it is intended to do.
> By using "UNTIL PARTITION", we could re-use the UNTIL keyword to handle other
> kinds of early-termination of selects that the coordinator might be able to
> do, such as stop retrieving additional rows from shards after a particular
> criterion was met.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6168) nodetool status reports 05 ownership when no keyspace is spacified
[
https://issues.apache.org/jira/browse/CASSANDRA-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800341#comment-13800341
]
Jonathan Ellis commented on CASSANDRA-6168:
---
Since we need KS to pick the right replication strategy, I vote we just leave
Owns out for no-KS situation. WDYT [~brandon.williams]?
> nodetool status reports 05 ownership when no keyspace is spacified
> --
>
> Key: CASSANDRA-6168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6168
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Patricio Echague
>Priority: Minor
>
> Seen in 1.2.10.
> Apologies if this is expected behavior. Nodetool status reports 0% ownership
> unless I add a keyspace name.
> nodetool help docs says:
> ..." status - Print cluster information (state, load, IDs,
> ...)"...
> output without keyspace name
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
>Rack
> UN 10.x.x.146 81.96 GB 256 0.0%
> a70c59b3-a667-4d76-ba5b-ba849ad672da r1
> UN 10.x.x.63 95.32 GB 256 0.0%
> f8cb7b10-4ebe-484a-a1c0-6cb2d053901b r1
> UN 10.x.x.184 89.54 GB 256 0.1%
> cd86c420-55e2-4d99-8ed9-d9ee8d6a9d9c r1
> UN 10.x.x.190 79.68 GB 256 0.0%
> 544c3906-bc02-400d-9fd2-1e39ecadd6ff r1
> UN 10.x.x.168 93.44 GB 256 0.7%
> 33be316f-1276-475d-90cf-2667950d3a2c r1
> UN 10.x.x.132 84.4 GB256 0.0%
> b327d9f1-cab0-4583-8e5e-95c50b4074fd r1
> Datacenter: DCOFFLINE
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
>Rack
> UN 10.x.x.62 56.09 GB 256 32.4%
> c8994d27-767b-431f-bdc2-9196eeeb6f44 r1
> UN 10.x.x.131 60.11 GB 256 32.8%
> 0b9d3314-039e-4f88-8ba6-d0f2885d9a30 r1
> UN 10.x.x.167 56.45 GB 256 34.0%
> ba76f4fe-4250-4839-a37d-c1a7c24e585d r1
> {code}
> and with keyspace. Example: nodetool status MYKSPS
> {code}
> Datacenter: DC1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 10.x.x.184 89.51 GB 256 50.0%
> cd86c420-55e2-4d99-8ed9-d9ee8d6a9d9c r1
> UN 10.x.x.146 81.96 GB 256 50.0%
> a70c59b3-a667-4d76-ba5b-ba849ad672da r1
> UN 10.x.x.168 93.44 GB 256 50.0%
> 33be316f-1276-475d-90cf-2667950d3a2c r1
> UN 10.x.x.63 95.32 GB 256 50.0%
> f8cb7b10-4ebe-484a-a1c0-6cb2d053901b r1
> UN 10.x.x.190 79.68 GB 256 50.0%
> 544c3906-bc02-400d-9fd2-1e39ecadd6ff r1
> UN 10.x.x.132 84.4 GB256 50.0%
> b327d9f1-cab0-4583-8e5e-95c50b4074fd r1
> Datacenter: DCOFFLINE
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 10.x.x.131 60.11 GB 256 32.8%
> 0b9d3314-039e-4f88-8ba6-d0f2885d9a30 r1
> UN 10.x.x.167 56.45 GB 256 34.7%
> ba76f4fe-4250-4839-a37d-c1a7c24e585d r1
> UN 10.x.x.62 56.09 GB 256 32.5%
> c8994d27-767b-431f-bdc2-9196eeeb6f44 r1
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6179) "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
[
https://issues.apache.org/jira/browse/CASSANDRA-6179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800338#comment-13800338
]
Jonathan Ellis commented on CASSANDRA-6179:
---
Anything suspicous jump out at you, Mikhail?
> "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
> -
>
> Key: CASSANDRA-6179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6179
> Project: Cassandra
> Issue Type: Bug
> Environment: JBOD layouts
>Reporter: J. Ryan Earl
>Assignee: Mikhail Stepura
>
> We recently noticed that the storage capacity on Cassandra nodes using JBOD
> layout was returning what looks close to the average data volume size,
> instead of the sum of all JBOD data volumes. It's not exactly an average and
> I haven't had time to dig into the code to see what it's really doing, it's
> like some sort of sample of the JBOD volumes sizes.
> So looking at the JBOD volumes we see:
> {noformat}
> [jre@cassandra2 ~]$ df -h
> FilesystemSize Used Avail Use% Mounted on
> [...]
> /dev/sdc1 1.1T 9.4G 1.1T 1% /data/1
> /dev/sdd1 1.1T 9.2G 1.1T 1% /data/2
> /dev/sde1 1.1T 11G 1.1T 1% /data/3
> /dev/sdf1 1.1T 11G 1.1T 1% /data/4
> /dev/sdg1 1.1T 9.2G 1.1T 1% /data/5
> /dev/sdh1 1.1T 11G 1.1T 1% /data/6
> /dev/sdi1 1.1T 9.8G 1.1T 1% /data/7
> {noformat}
> Looking at 'nodetool info' we see:
> {noformat}
> [jre@cassandra2 ~]$ nodetool info
> Token: (invoke with -T/--tokens to see all 256 tokens)
> ID : 631f0be3-ce52-4eb9-b48b-069fbfdf0a97
> Gossip active: true
> Thrift active: true
> Native Transport active: true
> Load : 10.57 GB
> {noformat}
> So there are 7 disks in a JBOD configuration in this example, the sum should
> be closer to 70G for each node. Maybe we're misinterpreting what this value
> should be, but things like OpsCenter appear to use this "load" value as the
> size of data on the local node, which I expect to be the sum of JBOD volumes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6179) "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
[
https://issues.apache.org/jira/browse/CASSANDRA-6179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6179:
--
Assignee: Mikhail Stepura
> "Load" calculated in "nodetool info" is strange/inaccurate in JBOD setups
> -
>
> Key: CASSANDRA-6179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6179
> Project: Cassandra
> Issue Type: Bug
> Environment: JBOD layouts
>Reporter: J. Ryan Earl
>Assignee: Mikhail Stepura
>
> We recently noticed that the storage capacity on Cassandra nodes using JBOD
> layout was returning what looks close to the average data volume size,
> instead of the sum of all JBOD data volumes. It's not exactly an average and
> I haven't had time to dig into the code to see what it's really doing, it's
> like some sort of sample of the JBOD volumes sizes.
> So looking at the JBOD volumes we see:
> {noformat}
> [jre@cassandra2 ~]$ df -h
> FilesystemSize Used Avail Use% Mounted on
> [...]
> /dev/sdc1 1.1T 9.4G 1.1T 1% /data/1
> /dev/sdd1 1.1T 9.2G 1.1T 1% /data/2
> /dev/sde1 1.1T 11G 1.1T 1% /data/3
> /dev/sdf1 1.1T 11G 1.1T 1% /data/4
> /dev/sdg1 1.1T 9.2G 1.1T 1% /data/5
> /dev/sdh1 1.1T 11G 1.1T 1% /data/6
> /dev/sdi1 1.1T 9.8G 1.1T 1% /data/7
> {noformat}
> Looking at 'nodetool info' we see:
> {noformat}
> [jre@cassandra2 ~]$ nodetool info
> Token: (invoke with -T/--tokens to see all 256 tokens)
> ID : 631f0be3-ce52-4eb9-b48b-069fbfdf0a97
> Gossip active: true
> Thrift active: true
> Native Transport active: true
> Load : 10.57 GB
> {noformat}
> So there are 7 disks in a JBOD configuration in this example, the sum should
> be closer to 70G for each node. Maybe we're misinterpreting what this value
> should be, but things like OpsCenter appear to use this "load" value as the
> size of data on the local node, which I expect to be the sum of JBOD volumes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6211) NPE in system.log
[
https://issues.apache.org/jira/browse/CASSANDRA-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800337#comment-13800337
]
Jonathan Ellis commented on CASSANDRA-6211:
---
I'm not sure how you've gotten an NPE logged without the rest of the
stacktrace. Are you doing anything unusual in deploying or configuring the log?
> NPE in system.log
> -
>
> Key: CASSANDRA-6211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6211
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> Linux hostname 2.6.32-279.el6.x86_64 #1 SMP Thu Jun 21 15:00:18 EDT 2012
> x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Mikhail Mazursky
> Labels: npe, nullpointerexception
>
> I wrote a stresstest to test C* and my code that uses CAS heavily. I see
> strange exception messages in logs:
> {noformat}
> ERROR [MutationStage:320] 2013-10-17 13:59:10,710 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:320,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:328] 2013-10-17 13:59:10,718 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:328,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:327] 2013-10-17 13:59:10,732 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:327,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:325] 2013-10-17 13:59:10,750 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:325,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:326] 2013-10-17 13:59:10,762 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:326,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:330] 2013-10-17 13:59:10,768 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:330,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:331] 2013-10-17 13:59:10,775 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:331,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:334] 2013-10-17 13:59:10,789 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:334,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:329] 2013-10-17 13:59:10,803 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:329,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:335] 2013-10-17 13:59:10,812 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:335,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:333] 2013-10-17 13:59:10,826 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:333,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:332] 2013-10-17 13:59:10,834 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:332,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:337] 2013-10-17 13:59:10,842 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:337,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:336] 2013-10-17 13:59:10,859 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:336,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:338] 2013-10-17 13:59:10,870 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:338,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:339] 2013-10-17 13:59:10,884 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:339,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:341] 2013-10-17 13:59:10,894 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:341,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:340] 2013-10-17 13:59:10,910 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:340,5,main]
> java.lang.NullPointerException
> ERROR [MutationStage:344] 2013-10-17 13:59:10,920 CassandraDaemon.java (line
> 185) Exception in thread Thread[MutationStage:344,5,main]
> java.lang.NullPointerException
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6212) TimestampType doesn't support pre-epoch long
[ https://issues.apache.org/jira/browse/CASSANDRA-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6212: -- Assignee: Mikhail Stepura (was: Lyuben Todorov) > TimestampType doesn't support pre-epoch long > > > Key: CASSANDRA-6212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6212 > Project: Cassandra > Issue Type: Bug > Components: API, Core >Reporter: Simon Hopkin >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 2.0.2 > > > org.apache.cassandra.db.marshal.TimestampType.dateStringToTimestamp() > contains a regular expression that checks to see if the String argument > contains a number. If so it parses it as a long timestamp. However > pre-epoch timestamps are negative and the code doesn't account for this so it > tries to parse it as a formatted Date. A tweak to the regular expression in > TimestampType.dateStringToTimestamp() would solve this issue. > I could use formatted date strings instead, but the TimestampType date parser > uses ISO8601 patterns which would cause the timestamp to be rounded to the > nearest second. > Currently I get the following exception message: > unable to coerce '-8640' to a formatted date (long) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6212) TimestampType doesn't support pre-epoch long
[ https://issues.apache.org/jira/browse/CASSANDRA-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800335#comment-13800335 ] Jonathan Ellis commented on CASSANDRA-6212: --- Can you take a stab at this, Mikhail? > TimestampType doesn't support pre-epoch long > > > Key: CASSANDRA-6212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6212 > Project: Cassandra > Issue Type: Bug > Components: API, Core >Reporter: Simon Hopkin >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 2.0.2 > > > org.apache.cassandra.db.marshal.TimestampType.dateStringToTimestamp() > contains a regular expression that checks to see if the String argument > contains a number. If so it parses it as a long timestamp. However > pre-epoch timestamps are negative and the code doesn't account for this so it > tries to parse it as a formatted Date. A tweak to the regular expression in > TimestampType.dateStringToTimestamp() would solve this issue. > I could use formatted date strings instead, but the TimestampType date parser > uses ISO8601 patterns which would cause the timestamp to be rounded to the > nearest second. > Currently I get the following exception message: > unable to coerce '-8640' to a formatted date (long) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CASSANDRA-6219) Add cause for IOException in OutboundTCPConnectio.WriteConnected
[ https://issues.apache.org/jira/browse/CASSANDRA-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-6219. --- Resolution: Not A Problem > Add cause for IOException in OutboundTCPConnectio.WriteConnected > > > Key: CASSANDRA-6219 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6219 > Project: Cassandra > Issue Type: Bug >Reporter: Benjamin Coverston >Priority: Minor > Attachments: 0001-added-cause-to-logging-message.patch > > > Can help for debugging connection issues. Attaching patch for 1.2. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
[ https://issues.apache.org/jira/browse/CASSANDRA-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-6221. - Resolution: Duplicate Fix Version/s: (was: 2.0.0) 2.0.2 Thanks, Mikhail. > CQL3 statements not executed properly inside BATCH operation. > - > > Key: CASSANDRA-6221 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6221 > Project: Cassandra > Issue Type: Bug > Environment: Running on Linux RHEL 6.2 with just a single node > cluster. A very basic configuration. You need a CQL3 table with a composite > key. Bug occurs while attempting to do both a DELETE and INSERT INTO > operation inside a BATCH block. >Reporter: Andy Klages > Fix For: 2.0.2 > > > I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements > within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be > ignored. Both statements operate on the same table and the first one does a > DELETE of an existing record, followed by an INSERT of a new record. The > table must have a composite key. NOTE that this worked fine in 1.2.10. > Here is a simple example of CQL3 statements to reproduce this: > -- Following table has a composite key. > CREATE TABLE users ( > user_id bigint, > id bigint, > namevarchar, > PRIMARY KEY(user_id, id) > ); > -- Insert record with key <100,1> > INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe'); > -- Following returns 1 row as expected. > SELECT * FROM users; > -- Attempt to delete <100,1> while inserting <100,2> as BATCH > BEGIN BATCH > DELETE FROM users WHERE user_id=100 AND id=1; > INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe'); > APPLY BATCH; > -- Following but should return only <100,2> but <100,1> is also returned > SELECT * FROM users; > The output from the first select which is correct: > user_id | id | name > -++-- > 100 | 1 | jdoe > The output from the second select which is incorrect is: > user_id | id | name > -++-- > 100 | 1 | jdoe > 100 | 2 | jdoe > Only the second row (<100,2>) should've been returned. This was the behavior > in 1.2.10. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
[ https://issues.apache.org/jira/browse/CASSANDRA-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800333#comment-13800333 ] Mikhail Stepura edited comment on CASSANDRA-6221 at 10/21/13 3:54 AM: -- Yep, fixed by https://issues.apache.org/jira/browse/CASSANDRA-6115 https://github.com/apache/cassandra/commit/8f88670f721f4ab4206c9b2d5594eabf1b46cebe was (Author: mishail): Yep, fixed by https://issues.apache.org/jira/browse/CASSANDRA-6115 > CQL3 statements not executed properly inside BATCH operation. > - > > Key: CASSANDRA-6221 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6221 > Project: Cassandra > Issue Type: Bug > Environment: Running on Linux RHEL 6.2 with just a single node > cluster. A very basic configuration. You need a CQL3 table with a composite > key. Bug occurs while attempting to do both a DELETE and INSERT INTO > operation inside a BATCH block. >Reporter: Andy Klages > Fix For: 2.0.0 > > > I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements > within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be > ignored. Both statements operate on the same table and the first one does a > DELETE of an existing record, followed by an INSERT of a new record. The > table must have a composite key. NOTE that this worked fine in 1.2.10. > Here is a simple example of CQL3 statements to reproduce this: > -- Following table has a composite key. > CREATE TABLE users ( > user_id bigint, > id bigint, > namevarchar, > PRIMARY KEY(user_id, id) > ); > -- Insert record with key <100,1> > INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe'); > -- Following returns 1 row as expected. > SELECT * FROM users; > -- Attempt to delete <100,1> while inserting <100,2> as BATCH > BEGIN BATCH > DELETE FROM users WHERE user_id=100 AND id=1; > INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe'); > APPLY BATCH; > -- Following but should return only <100,2> but <100,1> is also returned > SELECT * FROM users; > The output from the first select which is correct: > user_id | id | name > -++-- > 100 | 1 | jdoe > The output from the second select which is incorrect is: > user_id | id | name > -++-- > 100 | 1 | jdoe > 100 | 2 | jdoe > Only the second row (<100,2>) should've been returned. This was the behavior > in 1.2.10. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
[ https://issues.apache.org/jira/browse/CASSANDRA-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800333#comment-13800333 ] Mikhail Stepura commented on CASSANDRA-6221: Yep, fixed by https://issues.apache.org/jira/browse/CASSANDRA-6115 > CQL3 statements not executed properly inside BATCH operation. > - > > Key: CASSANDRA-6221 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6221 > Project: Cassandra > Issue Type: Bug > Environment: Running on Linux RHEL 6.2 with just a single node > cluster. A very basic configuration. You need a CQL3 table with a composite > key. Bug occurs while attempting to do both a DELETE and INSERT INTO > operation inside a BATCH block. >Reporter: Andy Klages > Fix For: 2.0.0 > > > I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements > within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be > ignored. Both statements operate on the same table and the first one does a > DELETE of an existing record, followed by an INSERT of a new record. The > table must have a composite key. NOTE that this worked fine in 1.2.10. > Here is a simple example of CQL3 statements to reproduce this: > -- Following table has a composite key. > CREATE TABLE users ( > user_id bigint, > id bigint, > namevarchar, > PRIMARY KEY(user_id, id) > ); > -- Insert record with key <100,1> > INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe'); > -- Following returns 1 row as expected. > SELECT * FROM users; > -- Attempt to delete <100,1> while inserting <100,2> as BATCH > BEGIN BATCH > DELETE FROM users WHERE user_id=100 AND id=1; > INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe'); > APPLY BATCH; > -- Following but should return only <100,2> but <100,1> is also returned > SELECT * FROM users; > The output from the first select which is correct: > user_id | id | name > -++-- > 100 | 1 | jdoe > The output from the second select which is incorrect is: > user_id | id | name > -++-- > 100 | 1 | jdoe > 100 | 2 | jdoe > Only the second row (<100,2>) should've been returned. This was the behavior > in 1.2.10. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
[
https://issues.apache.org/jira/browse/CASSANDRA-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800331#comment-13800331
]
Mikhail Stepura commented on CASSANDRA-6221:
I'm able to reproduce this in both {{cassandra-2.0.0}} and {{cassandra-2.0.1}}
tags, however with latest branch {{cassandra-2.0}} all works fine
> CQL3 statements not executed properly inside BATCH operation.
> -
>
> Key: CASSANDRA-6221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6221
> Project: Cassandra
> Issue Type: Bug
> Environment: Running on Linux RHEL 6.2 with just a single node
> cluster. A very basic configuration. You need a CQL3 table with a composite
> key. Bug occurs while attempting to do both a DELETE and INSERT INTO
> operation inside a BATCH block.
>Reporter: Andy Klages
> Fix For: 2.0.0
>
>
> I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements
> within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be
> ignored. Both statements operate on the same table and the first one does a
> DELETE of an existing record, followed by an INSERT of a new record. The
> table must have a composite key. NOTE that this worked fine in 1.2.10.
> Here is a simple example of CQL3 statements to reproduce this:
> -- Following table has a composite key.
> CREATE TABLE users (
> user_id bigint,
> id bigint,
> namevarchar,
> PRIMARY KEY(user_id, id)
> );
> -- Insert record with key <100,1>
> INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe');
> -- Following returns 1 row as expected.
> SELECT * FROM users;
> -- Attempt to delete <100,1> while inserting <100,2> as BATCH
> BEGIN BATCH
> DELETE FROM users WHERE user_id=100 AND id=1;
> INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe');
> APPLY BATCH;
> -- Following but should return only <100,2> but <100,1> is also returned
> SELECT * FROM users;
> The output from the first select which is correct:
> user_id | id | name
> -++--
> 100 | 1 | jdoe
> The output from the second select which is incorrect is:
> user_id | id | name
> -++--
> 100 | 1 | jdoe
> 100 | 2 | jdoe
> Only the second row (<100,2>) should've been returned. This was the behavior
> in 1.2.10.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[1/3] git commit: remove dead static noop method
Updated Branches:
refs/heads/trunk 6d8630724 -> 2d46a2bdb
remove dead static noop method
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df188cc8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df188cc8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df188cc8
Branch: refs/heads/trunk
Commit: df188cc8d286b3ad17e21332dd5633d9f974108e
Parents: 9afac24
Author: Dave Brosius
Authored: Sun Oct 20 22:24:40 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 22:24:40 2013 -0400
--
src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 -
1 file changed, 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df188cc8/src/java/org/apache/cassandra/gms/TokenSerializer.java
--
diff --git a/src/java/org/apache/cassandra/gms/TokenSerializer.java
b/src/java/org/apache/cassandra/gms/TokenSerializer.java
index cc7f177..ddc1730 100644
--- a/src/java/org/apache/cassandra/gms/TokenSerializer.java
+++ b/src/java/org/apache/cassandra/gms/TokenSerializer.java
@@ -59,9 +59,4 @@ public class TokenSerializer
}
return tokens;
}
-
-public static long serializedSize(Collection tokens, TypeSizes
typeSizes)
-{
-throw new UnsupportedOperationException();
-}
}
\ No newline at end of file
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2d46a2bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2d46a2bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2d46a2bd Branch: refs/heads/trunk Commit: 2d46a2bdbf49220bfb01f19dda5d211e622a54f3 Parents: 6d86307 1187c7a Author: Dave Brosius Authored: Sun Oct 20 22:28:40 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 22:28:40 2013 -0400 -- src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 - 1 file changed, 5 deletions(-) --
[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1187c7aa Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1187c7aa Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1187c7aa Branch: refs/heads/trunk Commit: 1187c7aa0aa609cfef1a15227d55b8c46eb59633 Parents: d00a233 df188cc Author: Dave Brosius Authored: Sun Oct 20 22:25:15 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 22:25:15 2013 -0400 -- src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 - 1 file changed, 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1187c7aa/src/java/org/apache/cassandra/gms/TokenSerializer.java --
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1187c7aa Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1187c7aa Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1187c7aa Branch: refs/heads/cassandra-2.0 Commit: 1187c7aa0aa609cfef1a15227d55b8c46eb59633 Parents: d00a233 df188cc Author: Dave Brosius Authored: Sun Oct 20 22:25:15 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 22:25:15 2013 -0400 -- src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 - 1 file changed, 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1187c7aa/src/java/org/apache/cassandra/gms/TokenSerializer.java --
[1/2] git commit: remove dead static noop method
Updated Branches:
refs/heads/cassandra-2.0 d00a2336b -> 1187c7aa0
remove dead static noop method
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df188cc8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df188cc8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df188cc8
Branch: refs/heads/cassandra-2.0
Commit: df188cc8d286b3ad17e21332dd5633d9f974108e
Parents: 9afac24
Author: Dave Brosius
Authored: Sun Oct 20 22:24:40 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 22:24:40 2013 -0400
--
src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 -
1 file changed, 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df188cc8/src/java/org/apache/cassandra/gms/TokenSerializer.java
--
diff --git a/src/java/org/apache/cassandra/gms/TokenSerializer.java
b/src/java/org/apache/cassandra/gms/TokenSerializer.java
index cc7f177..ddc1730 100644
--- a/src/java/org/apache/cassandra/gms/TokenSerializer.java
+++ b/src/java/org/apache/cassandra/gms/TokenSerializer.java
@@ -59,9 +59,4 @@ public class TokenSerializer
}
return tokens;
}
-
-public static long serializedSize(Collection tokens, TypeSizes
typeSizes)
-{
-throw new UnsupportedOperationException();
-}
}
\ No newline at end of file
git commit: remove dead static noop method
Updated Branches:
refs/heads/cassandra-1.2 9afac2410 -> df188cc8d
remove dead static noop method
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/df188cc8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/df188cc8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/df188cc8
Branch: refs/heads/cassandra-1.2
Commit: df188cc8d286b3ad17e21332dd5633d9f974108e
Parents: 9afac24
Author: Dave Brosius
Authored: Sun Oct 20 22:24:40 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 22:24:40 2013 -0400
--
src/java/org/apache/cassandra/gms/TokenSerializer.java | 5 -
1 file changed, 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/df188cc8/src/java/org/apache/cassandra/gms/TokenSerializer.java
--
diff --git a/src/java/org/apache/cassandra/gms/TokenSerializer.java
b/src/java/org/apache/cassandra/gms/TokenSerializer.java
index cc7f177..ddc1730 100644
--- a/src/java/org/apache/cassandra/gms/TokenSerializer.java
+++ b/src/java/org/apache/cassandra/gms/TokenSerializer.java
@@ -59,9 +59,4 @@ public class TokenSerializer
}
return tokens;
}
-
-public static long serializedSize(Collection tokens, TypeSizes
typeSizes)
-{
-throw new UnsupportedOperationException();
-}
}
\ No newline at end of file
[2/2] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d863072 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d863072 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d863072 Branch: refs/heads/trunk Commit: 6d86307242ac1304c15ae616d351e1d19fd014b6 Parents: 0b0c9e4 d00a233 Author: Dave Brosius Authored: Sun Oct 20 22:17:17 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 22:17:17 2013 -0400 -- src/java/org/apache/cassandra/dht/BootStrapper.java | 2 +- src/java/org/apache/cassandra/service/StorageService.java | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d863072/src/java/org/apache/cassandra/service/StorageService.java --
[1/2] git commit: remove dead 'load' parm to getBootstrapTokens
Updated Branches:
refs/heads/trunk 0b0c9e419 -> 6d8630724
remove dead 'load' parm to getBootstrapTokens
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d00a2336
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d00a2336
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d00a2336
Branch: refs/heads/trunk
Commit: d00a2336b7163ad8b4a0c0f4a848ad79c3652903
Parents: 72f47a4
Author: Dave Brosius
Authored: Sun Oct 20 22:16:38 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 22:16:38 2013 -0400
--
src/java/org/apache/cassandra/dht/BootStrapper.java | 2 +-
src/java/org/apache/cassandra/service/StorageService.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d00a2336/src/java/org/apache/cassandra/dht/BootStrapper.java
--
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index 57d8d94..0c22c23 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -92,7 +92,7 @@ public class BootStrapper
* otherwise, if num_tokens == 1, pick a token to assume half the load of
the most-loaded node.
* else choose num_tokens tokens at random
*/
-public static Collection getBootstrapTokens(final TokenMetadata
metadata, Map load) throws ConfigurationException
+public static Collection getBootstrapTokens(final TokenMetadata
metadata) throws ConfigurationException
{
Collection initialTokens =
DatabaseDescriptor.getInitialTokens();
// if user specified tokens, use those
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d00a2336/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index e45fb71..f171192 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -662,7 +662,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
throw new UnsupportedOperationException(s);
}
setMode(Mode.JOINING, "getting bootstrap token", true);
-tokens = BootStrapper.getBootstrapTokens(tokenMetadata,
LoadBroadcaster.instance.getLoadInfo());
+tokens = BootStrapper.getBootstrapTokens(tokenMetadata);
}
else
{
git commit: remove dead 'load' parm to getBootstrapTokens
Updated Branches:
refs/heads/cassandra-2.0 72f47a4e5 -> d00a2336b
remove dead 'load' parm to getBootstrapTokens
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d00a2336
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d00a2336
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d00a2336
Branch: refs/heads/cassandra-2.0
Commit: d00a2336b7163ad8b4a0c0f4a848ad79c3652903
Parents: 72f47a4
Author: Dave Brosius
Authored: Sun Oct 20 22:16:38 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 22:16:38 2013 -0400
--
src/java/org/apache/cassandra/dht/BootStrapper.java | 2 +-
src/java/org/apache/cassandra/service/StorageService.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d00a2336/src/java/org/apache/cassandra/dht/BootStrapper.java
--
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index 57d8d94..0c22c23 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -92,7 +92,7 @@ public class BootStrapper
* otherwise, if num_tokens == 1, pick a token to assume half the load of
the most-loaded node.
* else choose num_tokens tokens at random
*/
-public static Collection getBootstrapTokens(final TokenMetadata
metadata, Map load) throws ConfigurationException
+public static Collection getBootstrapTokens(final TokenMetadata
metadata) throws ConfigurationException
{
Collection initialTokens =
DatabaseDescriptor.getInitialTokens();
// if user specified tokens, use those
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d00a2336/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index e45fb71..f171192 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -662,7 +662,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
throw new UnsupportedOperationException(s);
}
setMode(Mode.JOINING, "getting bootstrap token", true);
-tokens = BootStrapper.getBootstrapTokens(tokenMetadata,
LoadBroadcaster.instance.getLoadInfo());
+tokens = BootStrapper.getBootstrapTokens(tokenMetadata);
}
else
{
[2/5] git commit: merge
merge Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/58014d30 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/58014d30 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/58014d30 Branch: refs/heads/trunk Commit: 58014d3038621a9bd732724d226b377917fd62e7 Parents: 74d63ba 232906d Author: Jonathan Ellis Authored: Sun Oct 20 02:08:52 2013 +0100 Committer: Jonathan Ellis Committed: Sun Oct 20 02:08:52 2013 +0100 -- NEWS.txt| 12 +++- .../io/compress/CompressedSequentialWriter.java | 12 .../org/apache/cassandra/service/StorageService.java| 12 ++-- 3 files changed, 29 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/58014d30/NEWS.txt -- diff --cc NEWS.txt index 7bd0d63,9d90ea7..69ab4fd --- a/NEWS.txt +++ b/NEWS.txt @@@ -26,12 -26,6 +26,12 @@@ New feature - Compaction history and stats are now saved to system keyspace (system.compaction_history table). You can access historiy via new 'nodetool compactionhistory' command or CQL. - - Added a new consistenct level, LOCAL_ONE, that forces all CL.ONE operations to ++- Added a new consistency level, LOCAL_ONE, that forces all CL.ONE operations to + execute only in the local datacenter. +- New replace_address to supplant the (now removed) replace_token and + replace_node workflows to replace a dead node in place. Works like the + old options, but takes the IP address of the node to be replaced. + 2.0.1 =
[1/5] git commit: Require CFRR batchSize to be at least 2 patch by Alex Liu and jbellis for CASSANDRA-6114
Updated Branches: refs/heads/trunk d32f1eb21 -> 0b0c9e419 Require CFRR batchSize to be at least 2 patch by Alex Liu and jbellis for CASSANDRA-6114 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/abe1395c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/abe1395c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/abe1395c Branch: refs/heads/trunk Commit: abe1395cbc29b21856d06b4bb3857fa7ae95eb18 Parents: e983ef1 Author: Jonathan Ellis Authored: Sun Oct 20 00:18:58 2013 +0100 Committer: Jonathan Ellis Committed: Sun Oct 20 02:08:08 2013 +0100 -- CHANGES.txt | 4 .../org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java| 3 +++ 2 files changed, 7 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/abe1395c/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 87be6fa..70bb919 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +1.2.12 + * (Hadoop) Require CFRR batchSize to be at least 2 (CASSANDRA-6114) + + 1.2.11 * Add a warning for small LCS sstable size (CASSANDRA-6191) * Add ability to list specific KS/CF combinations in nodetool cfstats (CASSANDRA-4191) http://git-wip-us.apache.org/repos/asf/cassandra/blob/abe1395c/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java -- diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java index 701260a..6846356 100644 --- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java +++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java @@ -144,6 +144,9 @@ public class ColumnFamilyRecordReader extends RecordReader
[4/5] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/72f47a4e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/72f47a4e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/72f47a4e Branch: refs/heads/trunk Commit: 72f47a4e59beb4f8fa8cc4533425871434f0690a Parents: 58014d3 9afac24 Author: Dave Brosius Authored: Sun Oct 20 21:56:52 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 21:56:52 2013 -0400 -- src/java/org/apache/cassandra/cli/CliMain.java | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/72f47a4e/src/java/org/apache/cassandra/cli/CliMain.java --
[5/5] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b0c9e41 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b0c9e41 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b0c9e41 Branch: refs/heads/trunk Commit: 0b0c9e419e46beb8f620fd4970cb7c482fd63d23 Parents: d32f1eb 72f47a4 Author: Dave Brosius Authored: Sun Oct 20 21:59:05 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 21:59:05 2013 -0400 -- src/java/org/apache/cassandra/cli/CliMain.java | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) --
[3/5] git commit: make sure files get closed
make sure files get closed
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9afac241
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9afac241
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9afac241
Branch: refs/heads/trunk
Commit: 9afac241090ee961bd1bcd3c9e78798ac1868d37
Parents: abe1395
Author: Dave Brosius
Authored: Sun Oct 20 21:52:08 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 21:52:08 2013 -0400
--
src/java/org/apache/cassandra/cli/CliMain.java | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afac241/src/java/org/apache/cassandra/cli/CliMain.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliMain.java
b/src/java/org/apache/cassandra/cli/CliMain.java
index 8c110c2..39a10db 100644
--- a/src/java/org/apache/cassandra/cli/CliMain.java
+++ b/src/java/org/apache/cassandra/cli/CliMain.java
@@ -264,18 +264,22 @@ public class CliMain
// load statements from file and process them
if (sessionState.inFileMode())
{
-FileReader fileReader;
+BufferedReader reader = null;
try
{
-fileReader = new FileReader(sessionState.filename);
-evaluateFileStatements(new BufferedReader(fileReader));
+reader = new BufferedReader(new
FileReader(sessionState.filename));
+evaluateFileStatements(reader);
}
catch (IOException e)
{
sessionState.err.println(e.getMessage());
System.exit(1);
}
+finally
+{
+FileUtils.closeQuietly(reader);
+}
return;
}
[3/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/72f47a4e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/72f47a4e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/72f47a4e Branch: refs/heads/cassandra-2.0 Commit: 72f47a4e59beb4f8fa8cc4533425871434f0690a Parents: 58014d3 9afac24 Author: Dave Brosius Authored: Sun Oct 20 21:56:52 2013 -0400 Committer: Dave Brosius Committed: Sun Oct 20 21:56:52 2013 -0400 -- src/java/org/apache/cassandra/cli/CliMain.java | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/72f47a4e/src/java/org/apache/cassandra/cli/CliMain.java --
[2/3] git commit: make sure files get closed
make sure files get closed
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9afac241
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9afac241
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9afac241
Branch: refs/heads/cassandra-2.0
Commit: 9afac241090ee961bd1bcd3c9e78798ac1868d37
Parents: abe1395
Author: Dave Brosius
Authored: Sun Oct 20 21:52:08 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 21:52:08 2013 -0400
--
src/java/org/apache/cassandra/cli/CliMain.java | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afac241/src/java/org/apache/cassandra/cli/CliMain.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliMain.java
b/src/java/org/apache/cassandra/cli/CliMain.java
index 8c110c2..39a10db 100644
--- a/src/java/org/apache/cassandra/cli/CliMain.java
+++ b/src/java/org/apache/cassandra/cli/CliMain.java
@@ -264,18 +264,22 @@ public class CliMain
// load statements from file and process them
if (sessionState.inFileMode())
{
-FileReader fileReader;
+BufferedReader reader = null;
try
{
-fileReader = new FileReader(sessionState.filename);
-evaluateFileStatements(new BufferedReader(fileReader));
+reader = new BufferedReader(new
FileReader(sessionState.filename));
+evaluateFileStatements(reader);
}
catch (IOException e)
{
sessionState.err.println(e.getMessage());
System.exit(1);
}
+finally
+{
+FileUtils.closeQuietly(reader);
+}
return;
}
[1/3] git commit: Require CFRR batchSize to be at least 2 patch by Alex Liu and jbellis for CASSANDRA-6114
Updated Branches: refs/heads/cassandra-2.0 58014d303 -> 72f47a4e5 Require CFRR batchSize to be at least 2 patch by Alex Liu and jbellis for CASSANDRA-6114 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/abe1395c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/abe1395c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/abe1395c Branch: refs/heads/cassandra-2.0 Commit: abe1395cbc29b21856d06b4bb3857fa7ae95eb18 Parents: e983ef1 Author: Jonathan Ellis Authored: Sun Oct 20 00:18:58 2013 +0100 Committer: Jonathan Ellis Committed: Sun Oct 20 02:08:08 2013 +0100 -- CHANGES.txt | 4 .../org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java| 3 +++ 2 files changed, 7 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/abe1395c/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 87be6fa..70bb919 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +1.2.12 + * (Hadoop) Require CFRR batchSize to be at least 2 (CASSANDRA-6114) + + 1.2.11 * Add a warning for small LCS sstable size (CASSANDRA-6191) * Add ability to list specific KS/CF combinations in nodetool cfstats (CASSANDRA-4191) http://git-wip-us.apache.org/repos/asf/cassandra/blob/abe1395c/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java -- diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java index 701260a..6846356 100644 --- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java +++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java @@ -144,6 +144,9 @@ public class ColumnFamilyRecordReader extends RecordReader
git commit: make sure files get closed
Updated Branches:
refs/heads/cassandra-1.2 abe1395cb -> 9afac2410
make sure files get closed
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9afac241
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9afac241
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9afac241
Branch: refs/heads/cassandra-1.2
Commit: 9afac241090ee961bd1bcd3c9e78798ac1868d37
Parents: abe1395
Author: Dave Brosius
Authored: Sun Oct 20 21:52:08 2013 -0400
Committer: Dave Brosius
Committed: Sun Oct 20 21:52:08 2013 -0400
--
src/java/org/apache/cassandra/cli/CliMain.java | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afac241/src/java/org/apache/cassandra/cli/CliMain.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliMain.java
b/src/java/org/apache/cassandra/cli/CliMain.java
index 8c110c2..39a10db 100644
--- a/src/java/org/apache/cassandra/cli/CliMain.java
+++ b/src/java/org/apache/cassandra/cli/CliMain.java
@@ -264,18 +264,22 @@ public class CliMain
// load statements from file and process them
if (sessionState.inFileMode())
{
-FileReader fileReader;
+BufferedReader reader = null;
try
{
-fileReader = new FileReader(sessionState.filename);
-evaluateFileStatements(new BufferedReader(fileReader));
+reader = new BufferedReader(new
FileReader(sessionState.filename));
+evaluateFileStatements(reader);
}
catch (IOException e)
{
sessionState.err.println(e.getMessage());
System.exit(1);
}
+finally
+{
+FileUtils.closeQuietly(reader);
+}
return;
}
[jira] [Commented] (CASSANDRA-6222) Allow multiple updates to a single wide row
[ https://issues.apache.org/jira/browse/CASSANDRA-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800263#comment-13800263 ] Brandon Williams commented on CASSANDRA-6222: - I'm not sure what you're asking for here. Magic? > Allow multiple updates to a single wide row > --- > > Key: CASSANDRA-6222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6222 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Ashot Golovenko > > Let's say I have the following table > CREATE TABLE rating ( > id bigint, > hid int, > r double, > PRIMARY KEY (id, hid); > In my case I have around 1000 records to insert with the same id value, so > basically I'm going to update physically the same row for 1000 times. It > would be nice to be able to do this update fast. Batching doesn't make it > really faster. Another case is to replace the row entirely with new values. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6220) Unable to select multiple entries using In clause on clustering part of compound key
[ https://issues.apache.org/jira/browse/CASSANDRA-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800239#comment-13800239 ] Jonathan Ellis commented on CASSANDRA-6220: --- Can you give an example of what we need to INSERT to reproduce? > Unable to select multiple entries using In clause on clustering part of > compound key > > > Key: CASSANDRA-6220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6220 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ashot Golovenko > > I have the following table: > CREATE TABLE rating ( > id bigint, > mid int, > hid int, > r double, > PRIMARY KEY ((id, mid), hid)); > And I get really really strange result sets on the following queries: > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329320; > hid | r > ---+ > 201329320 | 45.476 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329220; > hid | r > ---+--- > 201329220 | 53.62 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid in (201329320, 201329220); > hid | r > ---+ > 201329320 | 45.476 > (1 rows) <-- WRONG - should be two records > As you can see although both records exist I'm not able the fetch all of them > using in clause. By now I have to cycle my requests which are about 30 and I > find it highly inefficient given that I query physically the same row. > More of that - it doesn't happen all the time! For different id values > sometimes I get the correct dataset. > Ideally I'd like the following select to work: > SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; > Which doesn't work either. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6222) Allow multiple updates to a single wide row
Ashot Golovenko created CASSANDRA-6222: -- Summary: Allow multiple updates to a single wide row Key: CASSANDRA-6222 URL: https://issues.apache.org/jira/browse/CASSANDRA-6222 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Ashot Golovenko Let's say I have the following table CREATE TABLE rating ( id bigint, hid int, r double, PRIMARY KEY (id, hid); In my case I have around 1000 records to insert with the same id value, so basically I'm going to update physically the same row for 1000 times. It would be nice to be able to do this update fast. Batching doesn't make it really faster. Another case is to replace the row entirely with new values. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-5818) Duplicated error messages on directory creation error at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800227#comment-13800227
]
Mikhail Stepura commented on CASSANDRA-5818:
Few comments
* Permissions in a 1-7 format don't seem very informative for me. I would
rather stick with R. X, W, RW, RWX etc combination.
* For existing file objects the patch does not check whether the file can be
read and executed, and whether it's directory at all. It only checks if file is
writable ({{Directories.FileAction._2}}).
* There is no need to create a new {{File}} object in
{{!Directories.FileAction.hasPrivilege(new File(dataDir),
Directories.FileAction._2)}} since we already {{dir}} object.
> Duplicated error messages on directory creation error at startup
>
>
> Key: CASSANDRA-5818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5818
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michaël Figuière
>Assignee: koray sariteke
>Priority: Trivial
> Fix For: 2.1
>
> Attachments: patch.diff, trunk-5818.patch
>
>
> When I start Cassandra without the appropriate OS access rights to the
> default Cassandra directories, I get a flood of {{ERROR}} messages at
> startup, whereas one per directory would be more appropriate. See bellow:
> {code}
> ERROR 13:37:39,792 Failed to create
> /var/lib/cassandra/data/system/schema_triggers directory
> ERROR 13:37:39,797 Failed to create
> /var/lib/cassandra/data/system/schema_triggers directory
> ERROR 13:37:39,798 Failed to create
> /var/lib/cassandra/data/system/schema_triggers directory
> ERROR 13:37:39,798 Failed to create
> /var/lib/cassandra/data/system/schema_triggers directory
> ERROR 13:37:39,799 Failed to create
> /var/lib/cassandra/data/system/schema_triggers directory
> ERROR 13:37:39,800 Failed to create /var/lib/cassandra/data/system/batchlog
> directory
> ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog
> directory
> ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog
> directory
> ERROR 13:37:39,802 Failed to create /var/lib/cassandra/data/system/batchlog
> directory
> ERROR 13:37:39,802 Failed to create
> /var/lib/cassandra/data/system/peer_events directory
> ERROR 13:37:39,803 Failed to create
> /var/lib/cassandra/data/system/peer_events directory
> ERROR 13:37:39,803 Failed to create
> /var/lib/cassandra/data/system/peer_events directory
> ERROR 13:37:39,804 Failed to create
> /var/lib/cassandra/data/system/compactions_in_progress directory
> ERROR 13:37:39,805 Failed to create
> /var/lib/cassandra/data/system/compactions_in_progress directory
> ERROR 13:37:39,805 Failed to create
> /var/lib/cassandra/data/system/compactions_in_progress directory
> ERROR 13:37:39,806 Failed to create
> /var/lib/cassandra/data/system/compactions_in_progress directory
> ERROR 13:37:39,807 Failed to create
> /var/lib/cassandra/data/system/compactions_in_progress directory
> ERROR 13:37:39,808 Failed to create /var/lib/cassandra/data/system/hints
> directory
> ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints
> directory
> ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints
> directory
> ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints
> directory
> ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints
> directory
> ERROR 13:37:39,812 Failed to create
> /var/lib/cassandra/data/system/schema_keyspaces directory
> ERROR 13:37:39,812 Failed to create
> /var/lib/cassandra/data/system/schema_keyspaces directory
> ERROR 13:37:39,813 Failed to create
> /var/lib/cassandra/data/system/schema_keyspaces directory
> ERROR 13:37:39,814 Failed to create
> /var/lib/cassandra/data/system/schema_keyspaces directory
> ERROR 13:37:39,814 Failed to create
> /var/lib/cassandra/data/system/schema_keyspaces directory
> ERROR 13:37:39,815 Failed to create
> /var/lib/cassandra/data/system/range_xfers directory
> ERROR 13:37:39,816 Failed to create
> /var/lib/cassandra/data/system/range_xfers directory
> ERROR 13:37:39,817 Failed to create
> /var/lib/cassandra/data/system/range_xfers directory
> ERROR 13:37:39,817 Failed to create
> /var/lib/cassandra/data/system/schema_columnfamilies directory
> ERROR 13:37:39,818 Failed to create
> /var/lib/cassandra/data/system/schema_columnfamilies directory
> ERROR 13:37:39,818 Failed to create
> /var/lib/cassandra/data/system/schema_columnfamilies directory
> ERROR 13:37:39,820 Failed to create
> /var/lib/cassandra/data/system/schema_columnfamilies directory
> ERROR 13:37:39,821 Failed to create
> /var/lib/cassandra/data/system/schema_columnfamilies directory
> ERROR 13:37:39,821 Failed to create
> /var/lib/cassandra/data/system
[jira] [Created] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
Andy Klages created CASSANDRA-6221: -- Summary: CQL3 statements not executed properly inside BATCH operation. Key: CASSANDRA-6221 URL: https://issues.apache.org/jira/browse/CASSANDRA-6221 Project: Cassandra Issue Type: Bug Environment: Running on Linux RHEL 6.2 with just a single node cluster. A very basic configuration. You need a CQL3 table with a composite key. Bug occurs while attempting to do both a DELETE and INSERT INTO operation inside a BATCH block. Reporter: Andy Klages Fix For: 2.0.0 I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be ignored. Both statements operate on the same table and the first one does a DELETE of an existing record, followed by an INSERT of a new record. The table must have a composite key. NOTE that this worked fine in 1.2.10. Here is a simple example of CQL3 statements to reproduce this: -- Following table has a composite key. CREATE TABLE users ( user_id bigint, id bigint, namevarchar, PRIMARY KEY(user_id, id) ); -- Insert record with key <100,1> INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe'); -- Following returns 1 row as expected. SELECT * FROM users; -- Attempt to delete <100,1> while inserting <100,2> as BATCH BEGIN BATCH DELETE FROM users WHERE user_id=100 AND id=1; INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe'); APPLY BATCH; -- Following but should return only <100,2> but <100,1> is also returned SELECT * FROM users; The output from the first select which is correct: user_id | id | name -++-- 100 | 1 | jdoe The output from the second select which is incorrect is: user_id | id | name -++-- 100 | 1 | jdoe 100 | 2 | jdoe Only the second row (<100,2>) should've been returned. This was the behavior in 1.2.10. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6220) Unable to select multiple entries using In clause on clustering part of compound key
[ https://issues.apache.org/jira/browse/CASSANDRA-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800213#comment-13800213 ] Ashot Golovenko commented on CASSANDRA-6220: looks like the same problem > Unable to select multiple entries using In clause on clustering part of > compound key > > > Key: CASSANDRA-6220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6220 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ashot Golovenko > > I have the following table: > CREATE TABLE rating ( > id bigint, > mid int, > hid int, > r double, > PRIMARY KEY ((id, mid), hid)); > And I get really really strange result sets on the following queries: > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329320; > hid | r > ---+ > 201329320 | 45.476 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329220; > hid | r > ---+--- > 201329220 | 53.62 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid in (201329320, 201329220); > hid | r > ---+ > 201329320 | 45.476 > (1 rows) <-- WRONG - should be two records > As you can see although both records exist I'm not able the fetch all of them > using in clause. By now I have to cycle my requests which are about 30 and I > find it highly inefficient given that I query physically the same row. > More of that - it doesn't happen all the time! For different id values > sometimes I get the correct dataset. > Ideally I'd like the following select to work: > SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; > Which doesn't work either. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6137) CQL3 SELECT IN CLAUSE inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800212#comment-13800212
]
Ashot Golovenko commented on CASSANDRA-6137:
Oh, I think I've just created a duplicate bug.
Check this out - https://issues.apache.org/jira/browse/CASSANDRA-6220
Reproduced on 2.0.1
> CQL3 SELECT IN CLAUSE inconsistent
> --
>
> Key: CASSANDRA-6137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6137
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu AWS Cassandra 2.0.1 SINGLE NODE on EBS RAID
> storage
> OSX Cassandra 1.2.8 on SSD storage
>Reporter: Constance Eustace
>Priority: Minor
>
> I am elevating this to Critical after doing some trace and reproducing in
> several environments. No one has commented on this bug from the cassandra
> team, and I view unreliable/corrupted data a pretty big deal. We are
> considering pulling cassandra and using something else.
> We have the data state reproduced locally in an environment that we can set
> TRACE logging, attach a debugger, etc. Some guidance as to where to look
> would be greatly appreciated.
> --
> We are encountering inconsistent results from CQL3 queries with column keys
> using IN clause in WHERE. This has been reproduced in cqlsh and the jdbc
> driver.
> Rowkey is e_entid
> Column key is p_prop
> This returns roughly 21 rows for 21 column keys that match p_prop.
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB';
> These three queries each return one row for the requested single column key
> in the IN clause:
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:complete:count');
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:all:count');
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:fail:count');
> This query returns ONLY ONE ROW (one column key), not three as I would expect
> from the three-column-key IN clause:
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:complete:count','urn:bby:pcm:job:ingest:content:all:count','urn:bby:pcm:job:ingest:content:fail:count');
> This query does return two rows however for the requested two column keys:
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in (
>
> 'urn:bby:pcm:job:ingest:content:all:count','urn:bby:pcm:job:ingest:content:fail:count');
> cqlsh> describe table internal_submission.entity_job;
> CREATE TABLE entity_job (
> e_entid text,
> p_prop text,
> describes text,
> dndcondition text,
> e_entlinks text,
> e_entname text,
> e_enttype text,
> ingeststatus text,
> ingeststatusdetail text,
> p_flags text,
> p_propid text,
> p_proplinks text,
> p_storage text,
> p_subents text,
> p_val text,
> p_vallang text,
> p_vallinks text,
> p_valtype text,
> p_valunit text,
> p_vars text,
> partnerid text,
> referenceid text,
> size int,
> sourceip text,
> submitdate bigint,
> submitevent text,
> userid text,
> version text,
> PRIMARY KEY (e_entid, p_prop)
> ) WITH
> bloom_filter_fp_chance=0.01 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.00 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=0.10 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='NONE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompa
[jira] [Updated] (CASSANDRA-6220) Unable to select multiple entries using In clause on clustering part of compound key
[ https://issues.apache.org/jira/browse/CASSANDRA-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashot Golovenko updated CASSANDRA-6220: --- Description: I have the following table: CREATE TABLE rating ( id bigint, mid int, hid int, r double, PRIMARY KEY ((id, mid), hid)); And I get really really strange result sets on the following queries: cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329320; hid | r ---+ 201329320 | 45.476 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329220; hid | r ---+--- 201329220 | 53.62 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid in (201329320, 201329220); hid | r ---+ 201329320 | 45.476 (1 rows) <-- WRONG - should be two records As you can see although both records exist I'm not able the fetch all of them using in clause. By now I have to cycle my requests which are about 30 and I find it highly inefficient given that I query physically the same row. More of that - it doesn't happen all the time! For different id values sometimes I get the correct dataset. Ideally I'd like the following select to work: SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; Which doesn't work either. was: I have the following table: CREATE TABLE rating ( id bigint, mid int, hid int, r double, PRIMARY KEY ((id, mid), hid)); And I get really really strange result sets on the following queries: cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329320; hid | r ---+ 201329320 | 45.476 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329220; hid | r ---+--- 201329220 | 53.62 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid in (201329320, 201329220); hid | r ---+ 201329320 | 45.476 (1 rows) <-- WRONG - should be two records As you can see although both records exist I'm not able the fetch all of them using in clause. By now I have to cycle my requests which are about 30 and I find it highly inefficient given that I query physically the same row. Ideally I'd like the following select to work: SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; Which doesn't work either. > Unable to select multiple entries using In clause on clustering part of > compound key > > > Key: CASSANDRA-6220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6220 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ashot Golovenko > > I have the following table: > CREATE TABLE rating ( > id bigint, > mid int, > hid int, > r double, > PRIMARY KEY ((id, mid), hid)); > And I get really really strange result sets on the following queries: > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329320; > hid | r > ---+ > 201329320 | 45.476 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329220; > hid | r > ---+--- > 201329220 | 53.62 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid in (201329320, 201329220); > hid | r > ---+ > 201329320 | 45.476 > (1 rows) <-- WRONG - should be two records > As you can see although both records exist I'm not able the fetch all of them > using in clause. By now I have to cycle my requests which are about 30 and I > find it highly inefficient given that I query physically the same row. > More of that - it doesn't happen all the time! For different id values > sometimes I get the correct dataset. > Ideally I'd like the following select to work: > SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; > Which doesn't work either. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6220) Unable to select multiple entries using In clause on clustering part of compound key
[ https://issues.apache.org/jira/browse/CASSANDRA-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashot Golovenko updated CASSANDRA-6220: --- Description: I have the following table: CREATE TABLE rating ( id bigint, mid int, hid int, r double, PRIMARY KEY ((id, mid), hid)); And I get really really strange result sets on the following queries: cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329320; hid | r ---+ 201329320 | 45.476 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329220; hid | r ---+--- 201329220 | 53.62 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid in (201329320, 201329220); hid | r ---+ 201329320 | 45.476 (1 rows) <-- WRONG - should be two records As you can see although both records exist I'm not able the fetch all of them using in clause. By now I have to cycle my requests which are about 30 and I find it highly inefficient given that I query physically the same row. Ideally I'd like the following select to work: SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; Which doesn't work either. was: I have the following table: CREATE TABLE rating ( id bigint, mid int, hid int, r double, PRIMARY KEY ((id, mid), hid)); And I get really really strange result sets on the following queries: cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329320; hid | r ---+ 201329320 | 45.476 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329220; hid | r ---+--- 201329220 | 53.62 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid in (201329320, 201329220); hid | r ---+ 201329320 | 45.476 <-- WRONG - only one result As you can see although both records exist I'm not able the fetch all of them using in clause. By now I have to cycle my requests which are about 30 and I find it highly inefficient given that I query physically the same row. Ideally I'd like the following select to work: SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; Which doesn't work either. > Unable to select multiple entries using In clause on clustering part of > compound key > > > Key: CASSANDRA-6220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6220 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ashot Golovenko > > I have the following table: > CREATE TABLE rating ( > id bigint, > mid int, > hid int, > r double, > PRIMARY KEY ((id, mid), hid)); > And I get really really strange result sets on the following queries: > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329320; > hid | r > ---+ > 201329320 | 45.476 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid = 201329220; > hid | r > ---+--- > 201329220 | 53.62 > (1 rows) > cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 > and hid in (201329320, 201329220); > hid | r > ---+ > 201329320 | 45.476 > (1 rows) <-- WRONG - should be two records > As you can see although both records exist I'm not able the fetch all of them > using in clause. By now I have to cycle my requests which are about 30 and I > find it highly inefficient given that I query physically the same row. > Ideally I'd like the following select to work: > SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; > Which doesn't work either. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6137) CQL3 SELECT IN CLAUSE inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800205#comment-13800205
]
Constance Eustace commented on CASSANDRA-6137:
--
Has anyone reproduced this besides us?
> CQL3 SELECT IN CLAUSE inconsistent
> --
>
> Key: CASSANDRA-6137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6137
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu AWS Cassandra 2.0.1 SINGLE NODE on EBS RAID
> storage
> OSX Cassandra 1.2.8 on SSD storage
>Reporter: Constance Eustace
>Priority: Minor
>
> I am elevating this to Critical after doing some trace and reproducing in
> several environments. No one has commented on this bug from the cassandra
> team, and I view unreliable/corrupted data a pretty big deal. We are
> considering pulling cassandra and using something else.
> We have the data state reproduced locally in an environment that we can set
> TRACE logging, attach a debugger, etc. Some guidance as to where to look
> would be greatly appreciated.
> --
> We are encountering inconsistent results from CQL3 queries with column keys
> using IN clause in WHERE. This has been reproduced in cqlsh and the jdbc
> driver.
> Rowkey is e_entid
> Column key is p_prop
> This returns roughly 21 rows for 21 column keys that match p_prop.
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB';
> These three queries each return one row for the requested single column key
> in the IN clause:
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:complete:count');
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:all:count');
> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:fail:count');
> This query returns ONLY ONE ROW (one column key), not three as I would expect
> from the three-column-key IN clause:
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in
> ('urn:bby:pcm:job:ingest:content:complete:count','urn:bby:pcm:job:ingest:content:all:count','urn:bby:pcm:job:ingest:content:fail:count');
> This query does return two rows however for the requested two column keys:
> cqlsh> SELECT
> e_entid,e_entname,e_enttype,p_prop,p_flags,p_propid,e_entlinks,p_proplinks,p_subents,p_val,p_vallinks,p_vars
> FROM internal_submission.Entity_Job WHERE e_entid =
> '845b38f1-2b91-11e3-854d-126aad0075d4-CJOB' AND p_prop in (
>
> 'urn:bby:pcm:job:ingest:content:all:count','urn:bby:pcm:job:ingest:content:fail:count');
> cqlsh> describe table internal_submission.entity_job;
> CREATE TABLE entity_job (
> e_entid text,
> p_prop text,
> describes text,
> dndcondition text,
> e_entlinks text,
> e_entname text,
> e_enttype text,
> ingeststatus text,
> ingeststatusdetail text,
> p_flags text,
> p_propid text,
> p_proplinks text,
> p_storage text,
> p_subents text,
> p_val text,
> p_vallang text,
> p_vallinks text,
> p_valtype text,
> p_valunit text,
> p_vars text,
> partnerid text,
> referenceid text,
> size int,
> sourceip text,
> submitdate bigint,
> submitevent text,
> userid text,
> version text,
> PRIMARY KEY (e_entid, p_prop)
> ) WITH
> bloom_filter_fp_chance=0.01 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.00 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=0.10 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='NONE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={'sstable_compression': 'LZ4Compressor'};
> CREATE INDEX i
[jira] [Created] (CASSANDRA-6220) Unable to select multiple entries using In clause on clustering part of compound key
Ashot Golovenko created CASSANDRA-6220: -- Summary: Unable to select multiple entries using In clause on clustering part of compound key Key: CASSANDRA-6220 URL: https://issues.apache.org/jira/browse/CASSANDRA-6220 Project: Cassandra Issue Type: Bug Components: Core Reporter: Ashot Golovenko I have the following table: CREATE TABLE rating ( id bigint, mid int, hid int, r double, PRIMARY KEY ((id, mid), hid)); And I get really really strange result sets on the following queries: cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329320; hid | r ---+ 201329320 | 45.476 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid = 201329220; hid | r ---+--- 201329220 | 53.62 (1 rows) cqlsh:bm> SELECT hid, r FROM rating WHERE id = 755349113 and mid = 201310 and hid in (201329320, 201329220); hid | r ---+ 201329320 | 45.476 <-- WRONG - only one result As you can see although both records exist I'm not able the fetch all of them using in clause. By now I have to cycle my requests which are about 30 and I find it highly inefficient given that I query physically the same row. Ideally I'd like the following select to work: SELECT hid, r FROM rating WHERE id = 755349113 and mid in ? and hid in ?; Which doesn't work either. -- This message was sent by Atlassian JIRA (v6.1#6144)
