[jira] [Commented] (CASSANDRA-15670) Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy

2020-04-08 Thread Francisco Fernandez (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078036#comment-17078036
 ] 

Francisco Fernandez commented on CASSANDRA-15670:
-

I've opened a PR moving the logic to calculate the write endpoints for 
transient replication to concrete ReplicationStrategy classes. That might have 
a bit of impact on performance depending on the compiler optimizations, was 
that the reason for the previous approach? 

> Transient Replication: unable to insert data when the keyspace is configured 
> with the SimpleStrategy
> 
>
> Key: CASSANDRA-15670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Transient Replication
>Reporter: Alan Boudreault
>Assignee: Francisco Fernandez
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-rc
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> An error is thrown then trying to insert data with the transient replication 
> + SimpleStrategy configured.
> Test case:
> {code:java}
> CREATE KEYSPACE test_tr WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '3/1'};
> CREATE TABLE test_tr.users (id int PRIMARY KEY, username text) with 
> read_repair ='NONE';
> INSERT INTO test_tr.users (id, username) VALUES (1, 'alan');{code}
>  
> traceback:
> {code:java}
> ERROR [Native-Transport-Requests-8] 2020-03-27 10:27:17,188 
> ErrorMessage.java:450 - Unexpected exception during request
> java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy 
> cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
>   at 
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForRead(ConsistencyLevel.java:103)
>   at 
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForWrite(ConsistencyLevel.java:112)
>   at 
> org.apache.cassandra.locator.ReplicaPlans$2.select(ReplicaPlans.java:409)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:348)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:341)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:330)
>   at 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1171)
>   at 
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:713)
>   at 
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:951)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:475)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:453)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233)
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:108)
>   at 
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
>  {code}
>  
> --> 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L103



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED

2020-04-06 Thread Francisco Fernandez (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076223#comment-17076223
 ] 

Francisco Fernandez commented on CASSANDRA-15671:
-

Can you see the results using this 
[link|https://app.circleci.com/pipelines/github/fcofdez/cassandra?branch=CASSANDRA-15671]?

> Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> --
>
> Key: CASSANDRA-15671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15671
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Fernandez
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following test failure was observed:
> [junit-timeout] Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> [junit-timeout] expected:<4> but was:<5>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5>
> [junit-timeout]   at 
> org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190)
> Java 8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.

2020-04-06 Thread Francisco Fernandez (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076163#comment-17076163
 ] 

Francisco Fernandez commented on CASSANDRA-14773:
-

I've updated the patch including more test coverage.

> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Francisco Fernandez
>Priority: Urgent
>  Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from 
> CPU and memory perspective. Hovewer this improvement introduces the bug in 
> rounding. When rounding the expriration time which is close to  
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow 
> happens(because in scope of -CASSANDRA-13444-) data type for point was 
> changed from Long to Integer in order to reduce memory footprint), as result 
> point became negative and acts as silent poison for internal structures of 
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*. 
> Then depending of point intervals:
>  * The TombstoneHistogram produces wrong values when interval of points is 
> less then binSize, it is not critical.
>  * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point 
> intervals is great then  binSize, this case is very critical.
>  
> This is pull request [https://github.com/apache/cassandra/pull/273] that 
> reproduces the issue and provides the fix. 
>  
> The stacktrace when running(on codebase without fix) 
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
>  Source)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at

[jira] [Assigned] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest

2020-04-01 Thread Francisco Fernandez (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Fernandez reassigned CASSANDRA-15676:
---

Assignee: (was: Francisco Fernandez)

> flaky test testWriteUnknownResult- 
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failure observed in: 
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be 
> CasWriteUncertainException
>   at 
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-15670) Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy

2020-03-31 Thread Francisco Fernandez (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Fernandez reassigned CASSANDRA-15670:
---

Assignee: Francisco Fernandez

> Transient Replication: unable to insert data when the keyspace is configured 
> with the SimpleStrategy
> 
>
> Key: CASSANDRA-15670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Transient Replication
>Reporter: Alan Boudreault
>Assignee: Francisco Fernandez
>Priority: Normal
> Fix For: 4.0-rc
>
>
> An error is thrown then trying to insert data with the transient replication 
> + SimpleStrategy configured.
> Test case:
> {code:java}
> CREATE KEYSPACE test_tr WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '3/1'};
> CREATE TABLE test_tr.users (id int PRIMARY KEY, username text) with 
> read_repair ='NONE';
> INSERT INTO test_tr.users (id, username) VALUES (1, 'alan');{code}
>  
> traceback:
> {code:java}
> ERROR [Native-Transport-Requests-8] 2020-03-27 10:27:17,188 
> ErrorMessage.java:450 - Unexpected exception during request
> java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy 
> cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
>   at 
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForRead(ConsistencyLevel.java:103)
>   at 
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForWrite(ConsistencyLevel.java:112)
>   at 
> org.apache.cassandra.locator.ReplicaPlans$2.select(ReplicaPlans.java:409)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:348)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:341)
>   at 
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:330)
>   at 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1171)
>   at 
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:713)
>   at 
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:951)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:475)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:453)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233)
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:108)
>   at 
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
>  {code}
>  
> --> 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L103



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest

2020-03-31 Thread Francisco Fernandez (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Fernandez reassigned CASSANDRA-15676:
---

Assignee: Francisco Fernandez

> flaky test testWriteUnknownResult- 
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Francisco Fernandez
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failure observed in: 
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be 
> CasWriteUncertainException
>   at 
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED

2020-03-31 Thread Francisco Fernandez (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071834#comment-17071834
 ] 

Francisco Fernandez commented on CASSANDRA-15671:
-

[~e.dimitrova] you might want to review this when you have some free cycles? 
Thanks

> Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> --
>
> Key: CASSANDRA-15671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15671
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Fernandez
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following test failure was observed:
> [junit-timeout] Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> [junit-timeout] expected:<4> but was:<5>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5>
> [junit-timeout]   at 
> org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190)
> Java 8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED

2020-03-31 Thread Francisco Fernandez (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Fernandez updated CASSANDRA-15671:

Test and Documentation Plan: This is just a flaky test fix
 Status: Patch Available  (was: In Progress)

I've modified the tests to take into account only test triggered compactions 
for assertions.

[https://github.com/apache/cassandra/pull/503]

> Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> --
>
> Key: CASSANDRA-15671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15671
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Fernandez
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following test failure was observed:
> [junit-timeout] Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> [junit-timeout] expected:<4> but was:<5>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5>
> [junit-timeout]   at 
> org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190)
> Java 8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED

2020-03-30 Thread Francisco Fernandez (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Fernandez reassigned CASSANDRA-15671:
---

Assignee: Francisco Fernandez

> Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> --
>
> Key: CASSANDRA-15671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15671
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Fernandez
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> The following test failure was observed:
> [junit-timeout] Testcase: 
> testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest):
>FAILED
> [junit-timeout] expected:<4> but was:<5>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5>
> [junit-timeout]   at 
> org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190)
> Java 8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.

2020-03-26 Thread Francisco Fernandez (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067731#comment-17067731
 ] 

Francisco Fernandez commented on CASSANDRA-14773:
-

I've pushed a patch following the same ideas proposed originally and I've 
simplified the code as well. I think we're covering all overflows now.

[https://github.com/apache/cassandra/pull/491]

 

[~blerer] [~snazy] can you take a look? 

> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Francisco Fernandez
>Priority: Urgent
>  Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from 
> CPU and memory perspective. Hovewer this improvement introduces the bug in 
> rounding. When rounding the expriration time which is close to  
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow 
> happens(because in scope of -CASSANDRA-13444-) data type for point was 
> changed from Long to Integer in order to reduce memory footprint), as result 
> point became negative and acts as silent poison for internal structures of 
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*. 
> Then depending of point intervals:
>  * The TombstoneHistogram produces wrong values when interval of points is 
> less then binSize, it is not critical.
>  * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point 
> intervals is great then  binSize, this case is very critical.
>  
> This is pull request [https://github.com/apache/cassandra/pull/273] that 
> reproduces the issue and provides the fix. 
>  
> The stacktrace when running(on codebase without fix) 
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
>  Source)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at 
>

[jira] [Commented] (CASSANDRA-14377) Returning invalid JSON for NaN and Infinity float values

2018-08-02 Thread Francisco Fernandez (JIRA) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16566432#comment-16566432
 ] 

Francisco Fernandez commented on CASSANDRA-14377:
-

The patch LGTM.

> Returning invalid JSON for NaN and Infinity float values
> 
>
> Key: CASSANDRA-14377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14377
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Piotr Sarna
>Assignee: Benjamin Lerer
>Priority: Minor
>
> After inserting special float values like NaN and Infinity into a table:
> {{CREATE TABLE testme (t1 bigint, t2 float, t3 float, PRIMARY KEY (t1));}}
> {{INSERT INTO testme (t1, t2, t3) VALUES (7, NaN, Infinity);}}
> and returning them as JSON...
> {{cqlsh:demodb> select json * from testme;}}
> {{ [json]}}
> {{--}}
> {{ \{"t1": 7, "t2": NaN, "t3": Infinity}}}
>  
> ... the result will not be validated (e.g. with 
> [https://jsonlint.com/|https://jsonlint.com/)] ) because neither NaN nor 
> Infinity is a valid JSON value. The consensus seems to be returning JSON's 
> `null` in these cases, based on this article 
> [https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript]
>  and other similar ones.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum

2018-04-23 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447829#comment-16447829
 ] 

Francisco Fernandez commented on CASSANDRA-14167:
-

[Here|https://circleci.com/gh/fcofdez/cassandra/8] it is. If you need something 
else, just tell me. Thanks for the review!

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Assignee: Francisco Fernandez
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum

2018-04-22 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447207#comment-16447207
 ] 

Francisco Fernandez commented on CASSANDRA-14167:
-

The issue seems to be related to an optimization (CASSANDRA-10657) making 
counter cell empty. 
Here you can find a 
[patch|https://github.com/apache/cassandra/compare/cassandra-3.11...fcofdez:CASSANDRA-14167?expand=1]
 that solves the issue.

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-04-17 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440645#comment-16440645
 ] 

Francisco Fernandez commented on CASSANDRA-14286:
-

I see the problem now, thanks for pointing out. The code seems less complicated 
with your approach, so +1. Only one nit: there is a {{println}} on 
{{Selection.java}}.

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-04-09 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16430386#comment-16430386
 ] 

Francisco Fernandez commented on CASSANDRA-14286:
-

I've updated the trunk patch with the suggested approach, let me know if there 
is something that should be changed. Thanks for the review.

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-04-09 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
 ] 

Francisco Fernandez edited comment on CASSANDRA-14286 at 4/9/18 11:14 AM:
--

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch 
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
 
[Patch 
3.0|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.0?expand=1]
 
[Patch 
3.11|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.11?expand=1]
 
[Patch 
trunk|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-trunk-2?expand=1]
 


was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch 
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
 
[Patch 
3.0|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.0?expand=1]
 
[Patch 
3.11|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.11?expand=1]
 
[Patch 
trunk|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-trunk?expand=1]
 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-04-04 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
 ] 

Francisco Fernandez edited comment on CASSANDRA-14286 at 4/4/18 1:50 PM:
-

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch 
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
 
[Patch 
3.0|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.0?expand=1]
 
[Patch 
3.11|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.11?expand=1]
 
[Patch 
trunk|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-trunk?expand=1]
 


was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch 
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
 
[Patch 3.0|https://github.com/fcofdez/cassandra/tree/14286-3.0] 
[Patch 3.11|https://github.com/fcofdez/cassandra/tree/14286-3.11] 
[Patch trunk|https://github.com/fcofdez/cassandra/tree/14286-trunk] 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-04-04 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
 ] 

Francisco Fernandez edited comment on CASSANDRA-14286 at 4/4/18 1:49 PM:
-

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch 
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
 
[Patch 3.0|https://github.com/fcofdez/cassandra/tree/14286-3.0] 
[Patch 3.11|https://github.com/fcofdez/cassandra/tree/14286-3.11] 
[Patch trunk|https://github.com/fcofdez/cassandra/tree/14286-trunk] 


was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286-2?expand=1]
 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-03-23 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
 ] 

Francisco Fernandez edited comment on CASSANDRA-14286 at 3/23/18 8:23 AM:
--

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286-2?expand=1]
 


was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286?expand=1]
 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14245) SELECT JSON prints null on empty strings

2018-03-22 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409364#comment-16409364
 ] 

Francisco Fernandez commented on CASSANDRA-14245:
-

The problem is that the json serializer writes empty buffers as null instead of 
"".

[Patch|https://github.com/apache/cassandra/compare/cassandra-3.11...fcofdez:CASSANDRA-14245-3.11?expand=1]

> SELECT JSON prints null on empty strings
> 
>
> Key: CASSANDRA-14245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14245
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Cassandra 3.11.2, Ubuntu 16.04 LTS
>  
>Reporter: Norbert Schultz
>Assignee: Francisco Fernandez
>Priority: Major
>
> SELECT JSON reports an empty string as null.
>  
> Example:
> {code:java}
> cqlsh:unittest> create table test(id INT, name TEXT, PRIMARY KEY(id));
> cqlsh:unittest> insert into test (id, name) VALUES (1, 'Foo');
> cqlsh:unittest> insert into test (id, name) VALUES (2, '');
> cqlsh:unittest> insert into test (id, name) VALUES (3, null);
> cqlsh:unittest> select * from test;
> id | name
> +--
>   1 |  Foo
>   2 |     
>   3 | null
> (3 rows)
> cqlsh:unittest> select JSON * from test;
> [json]
> --
> {"id": 1, "name": "Foo"}
> {"id": 2, "name": null}
> {"id": 3, "name": null}
> (3 rows){code}
>  
> This even happens, if the string is part of the Primary Key, which makes the 
> generated string not insertable.
>  
> {code:java}
> cqlsh:unittest> create table test2 (id INT, name TEXT, age INT, PRIMARY 
> KEY(id, name));
> cqlsh:unittest> insert into test2 (id, name, age) VALUES (1, '', 42);
> cqlsh:unittest> select JSON * from test2;
> [json]
> 
> {"id": 1, "name": null, "age": 42}
> (1 rows)
> cqlsh:unittest> insert into test2 JSON '{"id": 1, "name": null, "age": 42}';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid 
> null value in condition for column name"{code}
>  
> On an older version of Cassandra (3.0.8) does not have this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-03-22 Thread Francisco Fernandez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
 ] 

Francisco Fernandez commented on CASSANDRA-14286:
-

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286?expand=1]
 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org