[jira] [Commented] (CASSANDRA-13149) AssertionError prepending to a list
[
https://issues.apache.org/jira/browse/CASSANDRA-13149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15858827#comment-15858827
]
Steven Warren commented on CASSANDRA-13149:
---
That is what I initially suspected and so confirmed ntp on all servers (and the
client machine as well). This bit of code seems to be sensitive down to the
millisecond so not sure ntp would help with that in any case.
> AssertionError prepending to a list
> ---
>
> Key: CASSANDRA-13149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13149
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: 3.0.8
>Reporter: Steven Warren
>
> Prepending to a list produces the following AssertionError randomly. Changing
> the update to append (and sort in the client) works around the issue.
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.cql3.Lists$PrecisionTime.getNext(Lists.java:275)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.cql3.Lists$Prepender.execute(Lists.java:430)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:94)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:682)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:613)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:420)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:408)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_101]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CASSANDRA-13149) AssertionError prepending to a list
Steven Warren created CASSANDRA-13149: - Summary: AssertionError prepending to a list Key: CASSANDRA-13149 URL: https://issues.apache.org/jira/browse/CASSANDRA-13149 Project: Cassandra Issue Type: Bug Components: CQL Environment: 3.0.8 Reporter: Steven Warren Prepending to a list produces the following AssertionError randomly. Changing the update to append (and sort in the client) works around the issue. java.lang.AssertionError: null at org.apache.cassandra.cql3.Lists$PrecisionTime.getNext(Lists.java:275) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.Lists$Prepender.execute(Lists.java:430) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:94) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:682) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:613) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:420) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:408) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130) ~[apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507) [apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401) [apache-cassandra-3.0.8.jar:3.0.8] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_101] at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164) [apache-cassandra-3.0.8.jar:3.0.8] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-3.0.8.jar:3.0.8] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903314#comment-14903314
]
Steven Warren edited comment on CASSANDRA-4386 at 9/23/15 2:43 PM:
---
I am fine with unordered rows for the IN clause, the current alternative with
parallel queries also returns unordered results. I don't have a use case for
the other operators, but assume that would be fine vs the alternative of not
being supported.
EDIT: Wouldn't the results come back in secondary index order though?
was (Author: swarren):
I am fine with unordered rows for the IN clause, the current alternative with
parallel queries also returns unordered results. I don't have a use case for
the other operators, but assume that would be fine vs the alternative of not
being supported.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14905226#comment-14905226
]
Steven Warren commented on CASSANDRA-4386:
--
I see, that makes sense!
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903314#comment-14903314
]
Steven Warren commented on CASSANDRA-4386:
--
I am fine with unordered rows for the IN clause, the current alternative with
parallel queries also returns unordered results. I don't have a use case for
the other operators, but assume that would be fine vs the alternative of not
being supported.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877264#comment-14877264
]
Steven Warren edited comment on CASSANDRA-4386 at 9/20/15 11:27 PM:
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 so it's 1-100 parallel
queries. However, without the in clause it's 1-100 parallel queries per primary
column value I want to specify. It would be much better to just write:
select value from x where pk = :y and primary in :values
That gives me a fixed number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
was (Author: swarren):
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column value I want to specify. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fixed number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877264#comment-14877264
]
Steven Warren commented on CASSANDRA-4386:
--
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up a primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column row I want to retrieve. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877264#comment-14877264
]
Steven Warren edited comment on CASSANDRA-4386 at 9/19/15 6:43 PM:
---
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column row I want to retrieve. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
was (Author: swarren):
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up a primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column row I want to retrieve. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877264#comment-14877264
]
Steven Warren edited comment on CASSANDRA-4386 at 9/19/15 6:47 PM:
---
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column value I want to specify. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fixed number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
was (Author: swarren):
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column value I want to specify. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4386) Allow cql to use the IN syntax on secondary index values
[
https://issues.apache.org/jira/browse/CASSANDRA-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877264#comment-14877264
]
Steven Warren edited comment on CASSANDRA-4386 at 9/19/15 6:44 PM:
---
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column value I want to specify. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
was (Author: swarren):
I'd like to make a case for raising the priority of this JIRA. I have a use
case which I don't think should be that unusual and where a secondary index IN
clause would be fantastic.
I have a set of wide rows ordered by an index (cluster key). I have a secondary
key on the primary column value.
If I want to look up by primary column value among the set of wide rows I have
to issue a query to each one:
select value from x where pk = :y and primary = :value
This is fine, the set of wide rows tends to be 1-100 rows so it's 1-100
parallel queries. However, without the in clause it's 1-100 parallel queries
per primary column row I want to retrieve. It would be much better to just
write:
select value from x where pk = :y and primary in :values
That gives me a fix number of queries to execute equal to the number of wide
rows in the set. This also should perform well since I'm specifying the
partition key and sending the parallel queries to the partition server for each
one.
> Allow cql to use the IN syntax on secondary index values
>
>
> Key: CASSANDRA-4386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
>
> Currently CQL has a syntax for using IN to get a set of rows with a set of
> keys. This would also be very helpful for use with columns with secondary
> indexes on them. Such as:
> {code}
> select * from users where first_name in ('françois','frank');
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
