[jira] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365134#comment-17365134 ] Adam Holmberg edited comment on CASSANDRA-16681 at 6/17/21, 9:26 PM: - Looking at this more today. I'm wondering if we should review and maybe move forward a patch for the race I described above. As mentioned, I could still get failures following that, but what I realized today: - Failures go from ~dozens per hundred runs to single digit - Even though one mode of flakiness fails the same assertion, I now believe it may be arriving there by a different mechanism Is it worth taking a look at those changes in the interest of getting more stability, and possibly spinning out investigation looking for more issues? was (Author: aholmber): Looking at this more today. I'm wondering if we should review and commit the patch for the race I described above. As mentioned, I could still get failures following that, but what I realized today: - Failures go from ~dozens per hundred runs to single digit - Even though one mode of flakiness fails the same assertion, I now believe it may be arriving there by a different mechanism Is it worth taking a look at those changes in the interest of getting more stability, and possibly spinning out investigation looking for more issues? > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365134#comment-17365134 ] Adam Holmberg commented on CASSANDRA-16681: --- Looking at this more today. I'm wondering if we should review and commit the patch for the race I described above. As mentioned, I could still get failures following that, but what I realized today: - Failures go from ~dozens per hundred runs to single digit - Even though one mode of flakiness fails the same assertion, I now believe it may be arriving there by a different mechanism Is it worth taking a look at those changes in the interest of getting more stability, and possibly spinning out investigation looking for more issues? > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364353#comment-17364353 ] Adam Holmberg edited comment on CASSANDRA-16681 at 6/16/21, 3:50 PM: - I haven't bottomed out on this, and I haven't produced a complete solution thus far. I'm going to continue looking at it intermittently as I'm able, but meanwhile I'll un-assign to make sure I'm not dissuading anyone else from taking it up. was (Author: aholmber): I haven't bottomed out on this, but I haven't produced a complete solution thus far. I'm going to continue looking at it intermittently as I'm able, but meanwhile I'll un-assign to make sure I'm not dissuading anyone else from taking it up. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364353#comment-17364353 ] Adam Holmberg commented on CASSANDRA-16681: --- I haven't bottomed out on this, but I haven't produced a complete solution thus far. I'm going to continue looking at it intermittently as I'm able, but meanwhile I'll un-assign to make sure I'm not dissuading anyone else from taking it up. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg reassigned CASSANDRA-16681: - Assignee: (was: Adam Holmberg) > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363014#comment-17363014 ] Adam Holmberg commented on CASSANDRA-16681: --- I have never reproduced locally. I could get it occasionally in the test multiplexer in CircleCI, but I have not developed any good leads. I have not spent a lot of time on it more recently. I was thinking of un-assigning and asking whether we should punt on this, unless someone has energy to devote to it. Thoughts? > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362196#comment-17362196
]
Adam Holmberg commented on CASSANDRA-16695:
---
+1 again, here. Thanks.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16733:
--
Fix Version/s: 4.0-rc
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-15588) 4.0 quality testing: Cluster Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-15588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-15588: -- Fix Version/s: (was: 4.0-rc) 4.0.x > 4.0 quality testing: Cluster Upgrade > > > Key: CASSANDRA-15588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15588 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.x > > > We've historically had numerous bugs concerning upgrading clusters from one > version to the other. Let's establish the supported upgrade path and ensure > that users can safely perform the upgrades in production. -- 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-15588) 4.0 quality testing: Cluster Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-15588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361894#comment-17361894 ] Adam Holmberg commented on CASSANDRA-15588: --- FixVer update: all child tickets are done and related links are both 4.0.x > 4.0 quality testing: Cluster Upgrade > > > Key: CASSANDRA-15588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15588 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.x > > > We've historically had numerous bugs concerning upgrading clusters from one > version to the other. Let's establish the supported upgrade path and ensure > that users can safely perform the upgrades in production. -- 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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361880#comment-17361880
]
Adam Holmberg commented on CASSANDRA-16695:
---
+1 on 4.0 patch.
{quote}I am wondering whether we should add them now or improve them after 4.0
{quote}
I am in favor of adding the tests now and improving later if it becomes a
problem.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361833#comment-17361833 ] Adam Holmberg commented on CASSANDRA-16262: --- I agree. I think it's time to re-assign or clear things that we are not posing as blockers. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16695:
--
Reviewers: Adam Holmberg
Status: Review In Progress (was: Patch Available)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360133#comment-17360133 ] Adam Holmberg commented on CASSANDRA-16681: --- bq. I have a patch with some synchronization around the release+status update that removes this flakiness. Getting back to this after some time, I'm less confident in the patch. I ported the fix without all my instrumentation and I'm back seeing flakiness. I will be looking into it more, but meanwhile I'm open to input if there are other leads. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356635#comment-17356635
]
Adam Holmberg commented on CASSANDRA-16681:
---
I think I've found a race. I know [~gianluca] also said he's working on a
patch, so I'm just going to post my findings here so we can compare notes.
What I think is happening:
LocalPool.addChunk
[evicts|https://lists.apache.org/thread.html/r75b09da8df530aa382605887a63dfa57b9c8d647b10f9064dd2b027a%40%3Cdev.cassandra.apache.org%3E]
a non-empty chunk in thread A. {{evict.release()}} finds a "not free" chunk
and does not recycle. Meanwhile, thread B does {{LocalPooll.put}}, freeing the
last buffer from the chunk. {{free}} returns -1, but the [status
CaS|https://github.com/apache/cassandra/blob/4acfd3bdf1acdb6b28059a49dd39823d7ea0689d/src/java/org/apache/cassandra/utils/memory/BufferPool.java#L808]
fails because thread A has not yet {{setEvicted}}. We therefore leave the
function with the chunk totally freed, but not recycled.
I have a patch with some synchronization around the release+status update that
removes this flakiness. Currently wondering how big an issue it actually is,
and if we care. Also pondering if this should be moved out of 4.0 for a number
of reasons:
1.) 4.0 is close and I don't have much appetite for touching such integral code
2.) I think this issue is low-impact since the chunk would just be GC'd instead
of being recycled
3.) The test is fairly pathological and this is perhaps even less likely to
happen in the running server (pure speculation)
Curious to get input on this and hear what Gianluca has found.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17351980#comment-17351980 ] Adam Holmberg commented on CASSANDRA-16681: --- Although I still think there is a race as described, more troubleshooting has indicated that it is not the cause for this assertion error most times. It's happening earlier on in the test when the threads would not be exiting. When it does happen, there is always only a single tracked chunk that has not been recycled a given time interval. It appears that the chunk is not being acquired or cycled in any way after entering this state. Still digging on it, but if anyone with more knowledge in the area wants to take a look, they are welcome. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0, 4.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg reassigned CASSANDRA-16681: - Assignee: Adam Holmberg > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0, 4.0-rc > > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347872#comment-17347872
]
Adam Holmberg edited comment on CASSANDRA-16681 at 5/19/21, 9:18 PM:
-
I think this is a test issue. I think we have a race
[here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284]
where, if threads exit after {{doneThreads}} is sampled, the assumptions
mentioned in the comment are violated.
I haven't assigned or posted a change because I'm still looking at some other
weirdness around this test and trying to understand how it was intended to work.
If anyone else wants to take a look and corroborate or just take the ticket,
it's fine by me.
was (Author: aholmber):
I think this is a test issue. I think we have a race
[here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284]
where, if threads exit after doneThreads is sampled, the assumptions mentioned
in the comment are violated.
I haven't assigned or posted a change because I'm still looking at some other
weirdness around this test and trying to understand how it was intended to work.
If anyone else wants to take a look and corroborate or just take the ticket,
it's fine by me.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347872#comment-17347872 ] Adam Holmberg commented on CASSANDRA-16681: --- I think this is a test issue. I think we have a race [here|https://github.com/apache/cassandra/blob/9a432418f2277c40a1fe4b64049688d6354ecdca/test/burn/org/apache/cassandra/utils/memory/LongBufferPoolTest.java#L276-L284] where, if threads exit after doneThreads is sampled, the assumptions mentioned in the comment are violated. I haven't assigned or posted a change because I'm still looking at some other weirdness around this test and trying to understand how it was intended to work. If anyone else wants to take a look and corroborate or just take the ticket, it's fine by me. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-rc > > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- 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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344799#comment-17344799
]
Adam Holmberg commented on CASSANDRA-16659:
---
+1 no concerns, better solution. Thanks.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344653#comment-17344653
]
Adam Holmberg commented on CASSANDRA-16659:
---
I agree it's a bit brittle, but thought it would be okay as a sanity check.
Totally cool making it a text file. Less sure about how that should be
organized in-tree. Would it be a resource to be embedded in the jar and read at
runtime? Happy to have you show or tell me how to do that.
Another thing I considered was just adding a utility "main" to the class that
the test would invoke to dump the keywords. Originally did not opt for that
because I didn't think it was worth the complexity for such a simple check.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Updated] (CASSANDRA-16652) "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
[
https://issues.apache.org/jira/browse/CASSANDRA-16652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16652:
--
Reviewers: Adam Holmberg, Adam Holmberg (was: Adam Holmberg)
Adam Holmberg, Adam Holmberg
Status: Review In Progress (was: Patch Available)
Patch looks good. +1
Two very minor comments on the commit.
> "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
> -
>
> Key: CASSANDRA-16652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16652
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> The "desc" statement on cqlsh 6.0.0 shipped with Cassandra 4.0 RC1 is not
> working correctly when it's connected to a Cassandra 3.x server.
> Steps to reproduce:
> * Ensure you have docker installed and running
> * Run the following docker commands to create and start a Cassandra 3.11
> container
> {code:java}
> ~ $ docker create --name cassandra3 cassandra:3.11.10
> 5d903e48e0661e39080198de5e8752356a5a666132211a500ea38af0fc2a0356
> ~ $ docker start cassandra3
> cassandra3
> ~ $ docker exec -ti cassandra3 bash
> {code}
> * Inside the docker container, try the default cqlsh version, make sure
> everything is working correctly
> {code:java}
> root@5d903e48e066:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> system_traces system_schema system_auth system system_distributed
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> resource_role_permissons_index role_permissions role_members roles
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> {code}
> * Okay, everything worked as expected. Now install {{git}} to clone the
> Cassandra 4.0 RC1 source code, and {{python3-six}}, which is a dependency of
> cqlsh
> {code:java}
> root@5d903e48e066:/# apt-get update -qq && apt-get install -qq git python3-six
> .. [truncated]
> {code}
> * Clone the Cassandra repository and checkout the cassandra-4.0-rc1 tag
> {code:java}
> root@5d903e48e066:/# git clone -b cassandra-4.0-rc1 --depth 1
> https://github.com/apache/cassandra.git cassandra-4.0-rc1
> Cloning into 'cassandra-4.0-rc1'...
> .. [truncated]
> {code}
> * Run the cqlsh from the Git repository, and then repeat all the cqlsh
> statements above
> {code:java}
> root@5d903e48e066:/# cd cassandra-4.0-rc1/bin
> root@5d903e48e066:/cassandra-4.0-rc1/bin# ./cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> root@5d903e48e066:/cassandra-4.0-rc1/bin#
> {code}
> "desc" did not work correctly, but "use" and "select" worked.
--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344001#comment-17344001
]
Adam Holmberg commented on CASSANDRA-16659:
---
This branch builds on Ekaterina's fix and adds a small sanity check unit test:
https://github.com/aholmberg/cassandra/pull/61/commits
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343982#comment-17343982
]
Adam Holmberg commented on CASSANDRA-16659:
---
I understand that we ported in the list derived from existing browser behavior.
While looking at possible ways to test I see there are some discrepancies
between this list and the one codified in
[{{ReservedKeywords.java}}|https://github.com/apache/cassandra/blob/f637198484c74b71429b1bc884d3fe9a86a4a926/src/java/org/apache/cassandra/cql3/ReservedKeywords.java].
{noformat}
Reserved keywords in cqlsh reserved keywords not read from source
.../cassandra/src/java/org/apache/cassandra/cql3/ReservedKeywords.java.
"{'unset', 'mbeans', 'mbean', 'replace', 'default'}
{noformat}
Actually as I write this it looks like those were recently unreserved in the
grammar, and maybe not flowed into the driver.
https://github.com/apache/cassandra/commit/b74d7370cc89fa899f47f50c825ddaed2dd05c3f
I have a small unit test that scans the above source and compares to the cqlsh
list. I will push shortly.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor':
[jira] [Comment Edited] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343982#comment-17343982
]
Adam Holmberg edited comment on CASSANDRA-16659 at 5/13/21, 4:09 PM:
-
I understand that we ported in the list derived from existing driver behavior.
While looking at possible ways to test I see there are some discrepancies
between this list and the one codified in
[{{ReservedKeywords.java}}|https://github.com/apache/cassandra/blob/f637198484c74b71429b1bc884d3fe9a86a4a926/src/java/org/apache/cassandra/cql3/ReservedKeywords.java].
{noformat}
Reserved keywords in cqlsh reserved keywords not read from source
.../cassandra/src/java/org/apache/cassandra/cql3/ReservedKeywords.java.
"{'unset', 'mbeans', 'mbean', 'replace', 'default'}
{noformat}
Actually as I write this it looks like those were recently unreserved in the
grammar, and maybe not flowed into the driver.
https://github.com/apache/cassandra/commit/b74d7370cc89fa899f47f50c825ddaed2dd05c3f
I have a small unit test that scans the above source and compares to the cqlsh
list. I will push shortly.
was (Author: aholmber):
I understand that we ported in the list derived from existing browser behavior.
While looking at possible ways to test I see there are some discrepancies
between this list and the one codified in
[{{ReservedKeywords.java}}|https://github.com/apache/cassandra/blob/f637198484c74b71429b1bc884d3fe9a86a4a926/src/java/org/apache/cassandra/cql3/ReservedKeywords.java].
{noformat}
Reserved keywords in cqlsh reserved keywords not read from source
.../cassandra/src/java/org/apache/cassandra/cql3/ReservedKeywords.java.
"{'unset', 'mbeans', 'mbean', 'replace', 'default'}
{noformat}
Actually as I write this it looks like those were recently unreserved in the
grammar, and maybe not flowed into the driver.
https://github.com/apache/cassandra/commit/b74d7370cc89fa899f47f50c825ddaed2dd05c3f
I have a small unit test that scans the above source and compares to the cqlsh
list. I will push shortly.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between,
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343612#comment-17343612
]
Adam Holmberg commented on CASSANDRA-16659:
---
Looking into my first idea, it was going to be more involved than anticipated.
I have another idea, but I don't think we should hold this ticket. I can
explore and propose a separate patch.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343507#comment-17343507
]
Adam Holmberg commented on CASSANDRA-16659:
---
Patch looks good to me. Do you think we should add a maintainer breadcrumb
[like
so|https://github.com/apache/cassandra/blob/4e47bfb3a1abb8074fb9a24f98a97dbf25806522/src/antlr/Lexer.g#L59-L60]?
A separate thought: what would you think of a unit test that makes sure this
list is in sync with the antlr files in-tree? I'm experimenting with that
locally. I can share if you think it's worth doing.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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] [Updated] (CASSANDRA-16653) Multinode counters don't get updated
[
https://issues.apache.org/jira/browse/CASSANDRA-16653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16653:
--
Fix Version/s: (was: 4.1)
4.0
> Multinode counters don't get updated
>
>
> Key: CASSANDRA-16653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16653
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Counters
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A multi node setup with counters doesn't update counters value. Works as
> expected on a single node though. Comes from
> [this|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/cql_tests.py#L460]
> test. Repro:
> {noformat}
> ccm create counters40
> ccm populate -n 2
> ccm start
> ccm node1 cqlsh
> CREATE KEYSPACE foo WITH REPLICATION = { 'class' :
> 'NetworkTopologyStrategy', 'datacenter1' : 1 } ;
> use foo;
> CREATE TABLE clicks ( userid int, url text, total counter, PRIMARY KEY
> (userid, url) ) WITH COMPACT STORAGE;
> ALTER TABLE clicks DROP COMPACT STORAGE;
> TRUNCATE clicks;
> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1
> UPDATE clicks SET total = total - 4 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1 *** Should be '-3'
> {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] [Updated] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16659:
--
Reviewers: Adam Holmberg
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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] [Updated] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16659:
--
Reviewers: Adam Holmberg, Adam Holmberg (was: Adam Holmberg)
Adam Holmberg, Adam Holmberg (was: Adam Holmberg)
Status: Review In Progress (was: Patch Available)
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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] [Updated] (CASSANDRA-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Fix Version/s: (was: 4.0.x)
4.0
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Fix Version/s: 4.0-rc2
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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] [Comment Edited] (CASSANDRA-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343369#comment-17343369
]
Adam Holmberg edited comment on CASSANDRA-16400 at 5/12/21, 5:04 PM:
-
[updated branch|https://github.com/aholmberg/cassandra/pull/58/files]
[clean
ci|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/767/testReport/cqlshlib.python3.jdk8.cython.test.test_unicode/TestCqlshUnicode/]
was (Author: aholmber):
[updated branch|https://github.com/aholmberg/cassandra/pull/58/files]
[clean
ci|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/767/testReport/cqlshlib.python3.jdk8.cython.test.test_unicode/TestCqlshUnicode/
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Status: Patch Available (was: In Progress)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343369#comment-17343369
]
Adam Holmberg commented on CASSANDRA-16400:
---
[updated branch|https://github.com/aholmberg/cassandra/pull/58/files]
[clean
ci|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/767/testReport/cqlshlib.python3.jdk8.cython.test.test_unicode/TestCqlshUnicode/
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342716#comment-17342716
]
Adam Holmberg commented on CASSANDRA-16659:
---
bq. PYTHON-1270 is planned for work soon?
I am not aware of anyone planning to work on this. We could provide a patch and
make a release happen if need be.
I'm wondering if instead we should continue the
[trend|https://issues.apache.org/jira/browse/CASSANDRA-14825?focusedCommentId=16662631=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16662631]
of getting drivers out of this game, and instead define keyword lists in cqlsh
code that ships with a given version. That would get away from the
inconsistencies coming from relying on a driver that is maintained separately,
and is designed to connect to varying server versions and variants.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This
[jira] [Updated] (CASSANDRA-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Fix Version/s: (was: 4.1)
(was: 4.0-rc2)
(was: 4.0)
4.0.x
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Status: In Progress (was: Patch Available)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342107#comment-17342107
]
Adam Holmberg commented on CASSANDRA-16400:
---
Previous CI run failed, apparently on a transient error in the build script.
Ekaterina started another one
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/761/].
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342103#comment-17342103
]
Adam Holmberg commented on CASSANDRA-16659:
---
I think this is because of the updated driver:
https://datastax-oss.atlassian.net/browse/PYTHON-1270
https://issues.apache.org/jira/browse/CASSANDRA-16240
https://github.com/datastax/python-driver/blob/master/cassandra/metadata.py#L62-L68
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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] [Updated] (CASSANDRA-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16658:
--
Test and Documentation Plan: Tested manually with CQLSH_PYTHON set in
Python 2.7, 3.6, 3.8
Status: Patch Available (was: In Progress)
[patch|https://github.com/aholmberg/cassandra/pull/60]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16658]
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341042#comment-17341042
]
Adam Holmberg commented on CASSANDRA-16400:
---
Giving this another try. I couldn't get the thing to fail the same way anywhere
but jenkins. While experimenting with this, I did recall that there were some
platform and runtime differences that sometimes cause non-visible control
sequences to appear in the echo buffer, blowing up the check for identical
echo. I updated the test to work around that since it's not actually the thing
being tested.
[updated
PR|https://github.com/aholmberg/cassandra/pull/58/commits/054e019025a953b1e35174c6f57141fe2a84df0c]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16400]
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Status: Patch Available (was: In Progress)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16658:
-
Assignee: Adam Holmberg
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340447#comment-17340447
]
Adam Holmberg commented on CASSANDRA-16400:
---
This was
[reverted|https://github.com/apache/cassandra/commit/a3db11831a0a7dd53c69da8df93bb9c35bc43eca]
when it [failed on
Jenkins|https://jenkins-cm4.apache.org/job/Cassandra-4.0/4/] running python3.
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16539) cqlsh encoding error with unicode in multi-line statement
[
https://issues.apache.org/jira/browse/CASSANDRA-16539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16539:
--
Resolution: Fixed
Status: Resolved (was: Open)
> cqlsh encoding error with unicode in multi-line statement
> -
>
> Key: CASSANDRA-16539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16539
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> {noformat}
> CREATE TABLE test.users (
> user_id int PRIMARY KEY,
> name text,
> state text
> )
> {noformat}
> Multiline cql with unicode characters will fail with an encoding error:
> {noformat}
> cqlsh> insert into test.users ( user_id, name, state ) values (
>... 6,
>... 'Bonne',
>... 'Année');
> 'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
> range(128)
> {noformat}
> This is only when running Python 2.7 and when python3 is not present in the
> environment.
--
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-16539) cqlsh encoding error with unicode in multi-line statement
[
https://issues.apache.org/jira/browse/CASSANDRA-16539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340443#comment-17340443
]
Adam Holmberg commented on CASSANDRA-16539:
---
I think we reopened the wrong one here. I'm going to close this and reopen the
other fix that built on this change.
> cqlsh encoding error with unicode in multi-line statement
> -
>
> Key: CASSANDRA-16539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16539
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> {noformat}
> CREATE TABLE test.users (
> user_id int PRIMARY KEY,
> name text,
> state text
> )
> {noformat}
> Multiline cql with unicode characters will fail with an encoding error:
> {noformat}
> cqlsh> insert into test.users ( user_id, name, state ) values (
>... 6,
>... 'Bonne',
>... 'Année');
> 'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
> range(128)
> {noformat}
> This is only when running Python 2.7 and when python3 is not present in the
> environment.
--
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-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339903#comment-17339903
]
Adam Holmberg commented on CASSANDRA-16643:
---
Thanks, but looks like that one failed on github clone.
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
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-16654) Junit RepeatableRunner flaky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-16654: -- Summary: Junit RepeatableRunner flaky tests helper (was: Junit RepeatableRunner falky tests helper) > Junit RepeatableRunner flaky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- 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-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16643:
--
Test and Documentation Plan: new unit test added
Status: Patch Available (was: In Progress)
I'm passing this along with python dtests blown up by something else. CI shows
java unit and dtests in good shape.
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
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-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339875#comment-17339875
]
Adam Holmberg commented on CASSANDRA-16643:
---
It seems some validation was omitted during some refactoring for 4.0. Proposed
patch adds metadata validation to AlterTableStatement, and a small unit test.
[patch|https://github.com/aholmberg/cassandra/pull/59]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16643]
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339113#comment-17339113
]
Adam Holmberg commented on CASSANDRA-16400:
---
[updated PR|https://github.com/aholmberg/cassandra/pull/58]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16400]
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339065#comment-17339065
]
Adam Holmberg commented on CASSANDRA-16400:
---
Sorry, that was a mistake. Will push an updated branch shortly.
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16643:
-
Assignee: Adam Holmberg
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
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-16639) cqlsh completion test fails sometimes
[
https://issues.apache.org/jira/browse/CASSANDRA-16639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16639:
--
Test and Documentation Plan:
Run existing tests.
Spun out another ticket to finish missing completion tests:
https://issues.apache.org/jira/browse/CASSANDRA-16640
Status: Patch Available (was: In Progress)
This happens when the [tempfile generated for keyspace
name|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/cassconnect.py#L43-L44]
contains a non-alphanumeric character as the last -- [spacing
changes|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/cqlhandling.py#L221-L224].
I'm proposing to change the keyspace name to be more predictable:
[patch|https://github.com/aholmberg/cassandra/pull/56]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16639]
> cqlsh completion test fails sometimes
> -
>
> Key: CASSANDRA-16639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16639
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> 'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS cqlshtests_9exbnsy_ ;'
> - F EXISTS cqlshtests_9exbnsy_;
> + F EXISTS cqlshtests_9exbnsy_ ;
> ? +
> : cqlsh completed 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
> cqlshtests_9exbnsy_ ;'
> """Fail immediately, with the given message."""
> >> raise self.failureException("'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS
> >> cqlshtests_9exbnsy_ ;'\n- F EXISTS cqlshtests_9exbnsy_;\n+ F EXISTS
> >> cqlshtests_9exbnsy_ ;\n? +\n : cqlsh completed
> >> 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
> >> cqlshtests_9exbnsy_ ;'")
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/453/testReport/junit/cqlshlib.python3.jdk8.cython.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_drop_keyspace/
--
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] [Created] (CASSANDRA-16640) Round out cqlsh completion test coverage
Adam Holmberg created CASSANDRA-16640: - Summary: Round out cqlsh completion test coverage Key: CASSANDRA-16640 URL: https://issues.apache.org/jira/browse/CASSANDRA-16640 Project: Cassandra Issue Type: Improvement Components: Test/unit Reporter: Adam Holmberg There are some missing tests in cqlsh completion. Some highlighted [here|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/test_cqlsh_completion.py#L808-L824]. There might be more needing coverage that are not enumerated. -- 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-16640) Round out cqlsh completion test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-16640: -- Change Category: Quality Assurance Complexity: Low Hanging Fruit Fix Version/s: 4.0.x Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Round out cqlsh completion test coverage > > > Key: CASSANDRA-16640 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16640 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Adam Holmberg >Priority: Low > Fix For: 4.0.x > > > There are some missing tests in cqlsh completion. Some highlighted > [here|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/test_cqlsh_completion.py#L808-L824]. > There might be more needing coverage that are not enumerated. -- 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-16639) cqlsh completion test fails sometimes
[
https://issues.apache.org/jira/browse/CASSANDRA-16639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16639:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Low Hanging Fruit
Component/s: Test/unit
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Low
Status: Open (was: Triage Needed)
> cqlsh completion test fails sometimes
> -
>
> Key: CASSANDRA-16639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16639
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> 'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS cqlshtests_9exbnsy_ ;'
> - F EXISTS cqlshtests_9exbnsy_;
> + F EXISTS cqlshtests_9exbnsy_ ;
> ? +
> : cqlsh completed 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
> cqlshtests_9exbnsy_ ;'
> """Fail immediately, with the given message."""
> >> raise self.failureException("'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS
> >> cqlshtests_9exbnsy_ ;'\n- F EXISTS cqlshtests_9exbnsy_;\n+ F EXISTS
> >> cqlshtests_9exbnsy_ ;\n? +\n : cqlsh completed
> >> 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
> >> cqlshtests_9exbnsy_ ;'")
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/453/testReport/junit/cqlshlib.python3.jdk8.cython.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_drop_keyspace/
--
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] [Created] (CASSANDRA-16639) cqlsh completion test fails sometimes
Adam Holmberg created CASSANDRA-16639:
-
Summary: cqlsh completion test fails sometimes
Key: CASSANDRA-16639
URL: https://issues.apache.org/jira/browse/CASSANDRA-16639
Project: Cassandra
Issue Type: Bug
Reporter: Adam Holmberg
Assignee: Adam Holmberg
{noformat}
'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS cqlshtests_9exbnsy_ ;'
- F EXISTS cqlshtests_9exbnsy_;
+ F EXISTS cqlshtests_9exbnsy_ ;
? +
: cqlsh completed 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
cqlshtests_9exbnsy_ ;'
"""Fail immediately, with the given message."""
>> raise self.failureException("'F EXISTS cqlshtests_9exbnsy_;' != 'F EXISTS
>> cqlshtests_9exbnsy_ ;'\n- F EXISTS cqlshtests_9exbnsy_;\n+ F EXISTS
>> cqlshtests_9exbnsy_ ;\n? +\n : cqlsh completed
>> 'F EXISTS cqlshtests_9exbnsy_;', but we expected 'F EXISTS
>> cqlshtests_9exbnsy_ ;'")
{noformat}
https://ci-cassandra.apache.org/job/Cassandra-trunk/453/testReport/junit/cqlshlib.python3.jdk8.cython.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_drop_keyspace/
--
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-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16637:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Local/Compaction/LCS
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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] [Created] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
Adam Holmberg created CASSANDRA-16637:
-
Summary:
LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
Key: CASSANDRA-16637
URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
Project: Cassandra
Issue Type: Bug
Reporter: Adam Holmberg
Test is failing occasionally as follows:
{noformat}
Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
at
org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
at
org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
at
org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
at
org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
{noformat}
[Recent
ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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-16539) cqlsh encoding error with unicode in multi-line statement
[
https://issues.apache.org/jira/browse/CASSANDRA-16539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16539:
--
Fix Version/s: (was: 4.0.x)
4.0
> cqlsh encoding error with unicode in multi-line statement
> -
>
> Key: CASSANDRA-16539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16539
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0
>
>
> {noformat}
> CREATE TABLE test.users (
> user_id int PRIMARY KEY,
> name text,
> state text
> )
> {noformat}
> Multiline cql with unicode characters will fail with an encoding error:
> {noformat}
> cqlsh> insert into test.users ( user_id, name, state ) values (
>... 6,
>... 'Bonne',
>... 'Année');
> 'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
> range(128)
> {noformat}
> This is only when running Python 2.7 and when python3 is not present in the
> environment.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Fix Version/s: (was: 4.0.x)
4.0
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16539) cqlsh encoding error with unicode in multi-line statement
[
https://issues.apache.org/jira/browse/CASSANDRA-16539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16539:
--
Description:
{noformat}
CREATE TABLE test.users (
user_id int PRIMARY KEY,
name text,
state text
)
{noformat}
Multiline cql with unicode characters will fail with an encoding error:
{noformat}
cqlsh> insert into test.users ( user_id, name, state ) values (
... 6,
... 'Bonne',
... 'Année');
'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
range(128)
{noformat}
This is only when running Python 2.7 and when python3 is not present in the
environment.
was:
{noformat}
CREATE TABLE test.users (
user_id int PRIMARY KEY,
name text,
state text
)
{noformat}
Multiline cql with unicode characters will fail with an encoding error:
{noformat}
cqlsh> insert into test.users ( user_id, name, state ) values (
... 6,
... 'Bonne',
... 'Année');
'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
range(128)
{noformat}
This is only when running Python 2.7 (deprecated in 4.0) and when python3 is
not present in the environment.
> cqlsh encoding error with unicode in multi-line statement
> -
>
> Key: CASSANDRA-16539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16539
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> CREATE TABLE test.users (
> user_id int PRIMARY KEY,
> name text,
> state text
> )
> {noformat}
> Multiline cql with unicode characters will fail with an encoding error:
> {noformat}
> cqlsh> insert into test.users ( user_id, name, state ) values (
>... 6,
>... 'Bonne',
>... 'Année');
> 'ascii' codec can't encode character u'\xe9' in position 74: ordinal not in
> range(128)
> {noformat}
> This is only when running Python 2.7 and when python3 is not present in the
> environment.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Description:
cqlsh fails to describe types with non-ascii characters. This is specific to
Python 2 and does not occur in Python 3 (only tested on trunk so far).
{code}
CREATE TYPE ks."ࠑ " (
v int
);
{code}
{noformat}
aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native protocol
v4]
Use HELP for help.
cqlsh> desc types;
Traceback (most recent call last):
File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
do_describe
self.describe_list(result)
File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
describe_list
names.append(str(row['name']))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in position
1: ordinal not in range(128)
{noformat}
3.11 appears to handle everything properly.
was:
cqlsh fails to describe types with non-ascii characters. This is specific to
Python 2 and does not occur in Python 3 (only tested on trunk so far).
{code}
CREATE TYPE ks."ࠑ " (
v int
);
{code}
{noformat}
aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native protocol
v4]
Use HELP for help.
cqlsh> desc types;
Traceback (most recent call last):
File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
do_describe
self.describe_list(result)
File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
describe_list
names.append(str(row['name']))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in position
1: ordinal not in range(128)
{noformat}
3.0.x is broken in a different way, regardless of what characters are in the
name:
{noformat}
cqlsh> create type ks.x ( v int );
cqlsh> desc types;
Keyspace system_schema
--
Keyspace system_auth
Keyspace system
---
Keyspace ks
---
list[i] not a string for i in 0
{noformat}
3.11 appears to handle everything properly.
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 3.0.x, 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Fix Version/s: (was: 3.0.x)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16596) Test org.apache.cassandra.net.AsyncPromiseTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-16596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330843#comment-17330843
]
Adam Holmberg commented on CASSANDRA-16596:
---
Thanks.
bq. MemtableSizeTest doesn't look like it has anything to do with your patch,
although it is new
I'll look into it later today.
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> -
>
> Key: CASSANDRA-16596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16596
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Not seen in Jenkins but reported a few times from CircleCI so it seems legit
> problem:
> [Test org.apache.cassandra.net.AsyncPromiseTest
> FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
> CircleCI
> [failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
> {noformat}
> Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
> 8
> junit.framework.AssertionFailedError: 8
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
> at
> org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
> at
> org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> {noformat}
> Also Caleb mentioned he is seeing it in another CI infra too
> CC [~maedhroz]
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17329450#comment-17329450 ] Adam Holmberg commented on CASSANDRA-16262: --- That's great to hear. Thanks for the heads up, insights, and all your work on that. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16596) Test org.apache.cassandra.net.AsyncPromiseTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-16596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16596:
--
Test and Documentation Plan:
Reproduced.
Modified existing unit test.
Left spinning for millions of iterations.
Status: Patch Available (was: In Progress)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> -
>
> Key: CASSANDRA-16596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16596
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Not seen in Jenkins but reported a few times from CircleCI so it seems legit
> problem:
> [Test org.apache.cassandra.net.AsyncPromiseTest
> FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
> CircleCI
> [failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
> {noformat}
> Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
> 8
> junit.framework.AssertionFailedError: 8
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
> at
> org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
> at
> org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> {noformat}
> Also Caleb mentioned he is seeing it in another CI infra too
> CC [~maedhroz]
--
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-16596) Test org.apache.cassandra.net.AsyncPromiseTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-16596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17329443#comment-17329443
]
Adam Holmberg commented on CASSANDRA-16596:
---
I believe this is nothing more interesting than an actual timeout. I could
reproduce this occasionally on a resource-constrained VM. I raised the timeout
and it never reproduced. Meanwhile I did some static analysis looking for races
around the async completions, but didn't see anything suspicious.
Brace yourself for this earth-shattering patch:
[patch|https://github.com/aholmberg/cassandra/pull/55]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16596]
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> -
>
> Key: CASSANDRA-16596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16596
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Not seen in Jenkins but reported a few times from CircleCI so it seems legit
> problem:
> [Test org.apache.cassandra.net.AsyncPromiseTest
> FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
> CircleCI
> [failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
> {noformat}
> Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
> 8
> junit.framework.AssertionFailedError: 8
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
> at
> org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
> at
> org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> {noformat}
> Also Caleb mentioned he is seeing it in another CI infra too
> CC [~maedhroz]
--
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-16566) Fix test testIsrepairedArg - org.apache.cassandra.tools.SSTableRepairedAtSetterTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325943#comment-17325943
]
Adam Holmberg commented on CASSANDRA-16566:
---
If it was parallelism, I'm wondering if this became a non-issue following
CASSANDRA-16595. Close for now?
> Fix test testIsrepairedArg -
> org.apache.cassandra.tools.SSTableRepairedAtSetterTest
> ---
>
> Key: CASSANDRA-16566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16566
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/874/workflows/0b0a1e36-107a-43c7-815f-bf8e61d3028d/jobs/5227/tests
> {code}
> junit.framework.AssertionFailedError:
> [org.apache.cassandra.tools.SSTableRepairedAtSetter,
> --really-set,
> --is-repaired,
>
> /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db]
> exited with code -1
> stderr:
> java.lang.RuntimeException: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db
> at
> org.apache.cassandra.tools.ToolRunner.runClassAsTool(ToolRunner.java:102)
> at org.apache.cassandra.tools.ToolRunner$2.get(ToolRunner.java:249)
> at org.apache.cassandra.tools.ToolRunner$2.get(ToolRunner.java:245)
> at
> org.apache.cassandra.tools.ToolRunner.invokeSupplier(ToolRunner.java:305)
> at
> org.apache.cassandra.tools.ToolRunner.invokeClass(ToolRunner.java:253)
> at
> org.apache.cassandra.tools.ToolRunner.invokeClass(ToolRunner.java:235)
> at
> org.apache.cassandra.tools.SSTableRepairedAtSetterTest.testIsrepairedArg(SSTableRepairedAtSetterTest.java:81)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data/legacy_sstables/legacy_ma_simple/ma-1-big-Data.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
> at
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
> at
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
> at java.nio.file.Files.readAttributes(Files.java:1737)
> at java.nio.file.Files.getLastModifiedTime(Files.java:2266)
> at
> org.apache.cassandra.tools.SSTableRepairedAtSetter.main(SSTableRepairedAtSetter.java:90)
> at
> org.apache.cassandra.tools.ToolRunner.runClassAsTool(ToolRunner.java:82)
> stdout:
> at
> org.apache.cassandra.tools.ToolRunner$ToolResult.assertExitCode(ToolRunner.java:408)
> at
> org.apache.cassandra.tools.ToolRunner$ToolResult.assertOnExitCode(ToolRunner.java:402)
> at
> org.apache.cassandra.tools.ToolRunner$ToolResult.assertOnCleanExit(ToolRunner.java:450)
> at
> org.apache.cassandra.tools.SSTableRepairedAtSetterTest.testIsrepairedArg(SSTableRepairedAtSetterTest.java:85)
> {code}
--
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-16596) Test org.apache.cassandra.net.AsyncPromiseTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-16596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16596:
-
Assignee: Adam Holmberg
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> -
>
> Key: CASSANDRA-16596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16596
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Not seen in Jenkins but reported a few times from CircleCI so it seems legit
> problem:
> [Test org.apache.cassandra.net.AsyncPromiseTest
> FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
> CircleCI
> [failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
> {noformat}
> Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
> 8
> junit.framework.AssertionFailedError: 8
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
> at
> org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
> at
> org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> {noformat}
> Also Caleb mentioned he is seeing it in another CI infra too
> CC [~maedhroz]
--
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-16596) Test org.apache.cassandra.net.AsyncPromiseTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-16596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16596:
--
Description:
Not seen in Jenkins but reported a few times from CircleCI so it seems legit
problem:
[Test org.apache.cassandra.net.AsyncPromiseTest
FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
CircleCI
[failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
{noformat}
Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
8
junit.framework.AssertionFailedError: 8
at
org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
at
org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
at
org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
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)
Caused by: java.util.concurrent.TimeoutException
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
at
org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
Test org.apache.cassandra.net.AsyncPromiseTest FAILED
{noformat}
Also Caleb mentioned he is seeing it in another CI infra too
CC [~maedhroz]
was:
Not seen in Jenkins but reported a few times from CircleCI so it seems legit
problem:
[Test org.apache.cassandra.net.AsyncPromiseTest
FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
CircleCI
[failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
Also Caleb mentioned he is seeing it in another CI infra too
CC [~maedhroz]
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> -
>
> Key: CASSANDRA-16596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16596
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> Not seen in Jenkins but reported a few times from CircleCI so it seems legit
> problem:
> [Test org.apache.cassandra.net.AsyncPromiseTest
> FAILED|https://jenkins-cm4.apache.org/job/Cassandra-trunk/434/testReport/org.apache.cassandra.net/AsyncPromiseTest/]
> CircleCI
> [failiure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/743/workflows/35cea1fd-6f38-4f09-9d7f-4673c34a9851/jobs/4104/parallel-runs/17]
> {noformat}
> Testcase: testFailure(org.apache.cassandra.net.AsyncPromiseTest): FAILED
> 8
> junit.framework.AssertionFailedError: 8
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:53)
> at
> org.apache.cassandra.net.TestAbstractAsyncPromise.testOneFailure(TestAbstractAsyncPromise.java:178)
> at
> org.apache.cassandra.net.AsyncPromiseTest.testFailure(AsyncPromiseTest.java:54)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.cassandra.net.TestAbstractPromise$Async.verify(TestAbstractPromise.java:49)
> Test org.apache.cassandra.net.AsyncPromiseTest FAILED
> {noformat}
> Also Caleb mentioned he is seeing it in another CI infra too
> CC [~maedhroz]
--
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-13191) test failure in org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
[
https://issues.apache.org/jira/browse/CASSANDRA-13191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-13191:
--
Resolution: Fixed
Status: Resolved (was: Open)
Fixed by CASSANDRA-16595, which merged yesterday.
> test failure in
> org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
> ---
>
> Key: CASSANDRA-13191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13191
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing, Test/unit
>Reporter: Michael Shuler
>Priority: Normal
> Labels: test-failure
> Fix For: 4.0-rc
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_testall/1392/testReport/org.apache.cassandra.hints/HintsBufferPoolTest/testBackpressure
> {noformat}
> Error Message
> Connection reset
> Stacktrace
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:209)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at
> org.jboss.byteman.agent.submit.Submit$Comm.readResponse(Submit.java:941)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:790)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at
> org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:268)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:369)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
> Standard Output
> ERROR [main] 2017-02-07 11:03:07,465 ?:? - SLF4J: stderr
> INFO [main] 2017-02-07 11:03:07,650 ?:? - Configuration location:
> file:/home/automaton/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2017-02-07 11:03:07,651 ?:? - Loading settings from
> file:/home/automaton/cassandra/test/conf/cassandra.yaml
> INFO [main] 2017-02-07 11:03:08,225 ?:? - Node
> configuration:[allocate_tokens_for_keyspace=null; authenticator=null;
> authorizer=null; auto_bootstrap=true; auto_snapshot=true;
> back_pressure_enabled=false; back_pressure_strategy=null;
> batch_size_fail_threshold_in_kb=50; batch_size_warn_threshold_in_kb=5;
> batchlog_replay_throttle_in_kb=1024; broadcast_address=null;
> broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=true;
> cas_contention_timeout_in_ms=1000; cdc_enabled=false;
> cdc_free_space_check_interval_ms=250;
> cdc_raw_directory=build/test/cassandra/cdc_raw:222; cdc_total_space_in_mb=0;
> client_encryption_options=; cluster_name=Test Cluster;
> column_index_cache_size_in_kb=2; column_index_size_in_kb=4;
> commit_failure_policy=stop; commitlog_compression=null;
> commitlog_directory=build/test/cassandra/commitlog:222;
> commitlog_max_compression_buffers_in_pool=3;
> commitlog_periodic_queue_size=-1; commitlog_segment_size_in_mb=5;
> commitlog_sync=batch; commitlog_sync_batch_window_in_ms=1.0;
> commitlog_sync_period_in_ms=0; commitlog_total_space_in_mb=null;
> compaction_large_partition_warning_threshold_mb=100;
> compaction_throughput_mb_per_sec=0; concurrent_compactors=4;
> concurrent_counter_writes=32; concurrent_materialized_view_writes=32;
> concurrent_reads=32; concurrent_replicates=null; concurrent_writes=32;
> counter_cache_keys_to_save=2147483647; counter_cache_save_period=7200;
> counter_cache_size_in_mb=null; counter_write_request_timeout_in_ms=5000;
> credentials_cache_max_entries=1000; credentials_update_interval_in_ms=-1;
> credentials_validity_in_ms=2000; cross_node_timeout=false;
> data_file_directories=[Ljava.lang.String;@e7edb54; disk_access_mode=mmap;
> disk_failure_policy=ignore; disk_optimization_estimate_percentile=0.95;
> disk_optimization_page_cross_chance=0.1; disk_optimization_strategy=ssd;
> dynamic_snitch=true; dynamic_snitch_badness_threshold=0.1;
> dynamic_snitch_reset_interval_in_ms=60;
> dynamic_snitch_update_interval_in_ms=100;
> enable_scripted_user_defined_functions=true;
> enable_user_defined_functions=true;
> enable_user_defined_functions_threads=true; encryption_options=null;
> endpoint_snitch=org.apache.cassandra.locator.SimpleSnitch;
> file_cache_size_in_mb=null;
[jira] [Updated] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16586:
--
Test and Documentation Plan: JVM upgrade test modified, run
Status: Patch Available (was: In Progress)
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by
[jira] [Commented] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324024#comment-17324024
]
Adam Holmberg commented on CASSANDRA-16586:
---
I ran into trouble getting the shutdown approach working with some of the
earlier versions. Instead I pushed a simplified version that
1.) extends the request timeout by a second to get away from false negatives
2.) uses message filtering to effect timeouts to nodes when "down"
test run
[here|https://app.circleci.com/pipelines/github/aholmberg/cassandra/250/workflows/c139a296-8b51-4e33-881f-ff811dbec0d3/jobs/2998/parallel-runs/0?filterBy=ALL]
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323974#comment-17323974
]
Adam Holmberg commented on CASSANDRA-16524:
---
I understand that this was found during upgrade, but imo an upgrade test is
fairly abstract characterization of this fix. [~gianluca] said creating the
cert chain was fairly involved. Do you think it's worth codifying that in an
integration test? I had been thinking that the new unit tests were sufficient.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds
[jira] [Assigned] (CASSANDRA-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16238:
-
Assignee: (was: Adam Holmberg)
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {code}
--
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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-16599: -- Reviewers: Adam Holmberg, Michael Semb Wever (was: Michael Semb Wever) > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip instead -- 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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322306#comment-17322306 ] Adam Holmberg commented on CASSANDRA-16599: --- The branch looks good to me. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip instead -- 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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17321299#comment-17321299 ] Adam Holmberg commented on CASSANDRA-16599: --- bq. some companies may enable GitHub two-factor auth which blocks the raw API from working in CI [~dcapwell] can you help me understand this a little better? IIUC Personal Access Tokens can sometimes be used for orgs with 2FA or SSO auth running in non-interactive contexts. Is that not applicable here? bq. Is the python driver getting donated? I believe that is still the intent, but there is still work to do, and we were wanting to get past 4.0 as well. There's an open CEP discussion about it. imo, we should go back to bundling the source zip until the drivers land in ASF, then we could revisit how we include based on how builds and releases are done there. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip instead -- 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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17321278#comment-17321278 ] Adam Holmberg commented on CASSANDRA-16599: --- re: #2 -- Could this package in particular be excepted from the concerns around dependencies in tree since the zip is actually a *source* distribution? > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip instead -- 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-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17320637#comment-17320637
]
Adam Holmberg commented on CASSANDRA-16586:
---
CI says I broke the other availability upgrade tests, so sitting on this until
I can get back into it.
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message
[jira] [Commented] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17320636#comment-17320636 ] Adam Holmberg commented on CASSANDRA-16599: --- I will definitely take a closer look tomorrow, but at first blush I think this will only work when we are synch'd on an actual driver release. This is more commonly not the case as we bundle snapshots during new protocol evolution. Maybe this will be less common with the protocol maturing, but thought I should at least throw it out there. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip instead -- 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-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17320548#comment-17320548
]
Adam Holmberg commented on CASSANDRA-16586:
---
As shown in the error in the description, we're occasionally bumping into
coordinator timeouts, which are [set to a smaller
value|https://github.com/apache/cassandra/blob/6665fc29b33abcc26aad4cecbfee88225b0a7225/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeAvailabilityTestBase.java#L64-L65]
by the test. I assume they were set lower to make the test timeout faster when
we are [expecting a
failure|https://github.com/apache/cassandra/blob/6665fc29b33abcc26aad4cecbfee88225b0a7225/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeAvailabilityTestBase.java#L113].
However, simply raising them then causes the test to occasionally fail in a
different way ({{Failure}} instead of {{Timeout}}) if the node shutdown occurs
mid-request.
I'm pushing a potential patch that makes sure the coordinator sees the node as
down, then expects an {{UnavailableException}}. I'm not sure if/why the
{{Timeout}} exception would be essential to this test, but if that is preferred
we could look at another technique of inducing the timeout deterministically
without making it cause flakiness.
[patch|https://github.com/aholmberg/cassandra/pull/54]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16586]
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
>
[jira] [Commented] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319719#comment-17319719
]
Adam Holmberg commented on CASSANDRA-16586:
---
The failure is easily reproduced. Aside from the timeout error in the
description, I'm also occasionally seeing it fail with the following:
{noformat}
[junit-timeout] Unexpected error in case ALL-ONE with upgraded coordinator and
2 nodes down
[junit-timeout] junit.framework.AssertionFailedError: Unexpected error in case
ALL-ONE with upgraded coordinator and 2 nodes down
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:187)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:52)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:150)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:113)
{noformat}
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
>
[jira] [Assigned] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16586:
-
Assignee: Adam Holmberg
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318323#comment-17318323
]
Adam Holmberg edited comment on CASSANDRA-16582 at 4/10/21, 1:09 AM:
-
Benjamin was working on this and had to end the week while working through some
test issues. I built on his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
was (Author: aholmber):
Benjamin was working on this and had to end the week while working through some
test issues. I took his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
>
[jira] [Comment Edited] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318323#comment-17318323
]
Adam Holmberg edited comment on CASSANDRA-16582 at 4/10/21, 1:08 AM:
-
Benjamin was working on this and had to end the week while working through some
test issues. I took his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
was (Author: aholmber):
Benjamin was working on this and had to end the week in the middle of working
through some test issues. I took the branch and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
>
[jira] [Commented] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318401#comment-17318401
]
Adam Holmberg commented on CASSANDRA-16582:
---
Circle ran well with one apparently unrelated timeout failure.
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
>
[jira] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16582:
--
Authors: Adam Holmberg, Benjamin Lerer (was: Adam Holmberg)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
>
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16577:
--
Reviewers: Andres de la Peña, Adam Holmberg (was: Adam Holmberg, Andres de
la Peña)
Andres de la Peña, Adam Holmberg (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{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] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16577:
--
Status: Patch Available (was: Open)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{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] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16582:
--
Test and Documentation Plan: New jvm upgrade test is added.
Status: Patch Available (was: In Progress)
Benjamin was working on this and had to end the week in the middle of working
through some test issues. I took the branch and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
>
[jira] [Assigned] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16582:
-
Assignee: Adam Holmberg
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
>
[jira] [Assigned] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16582:
-
Assignee: (was: Benjamin Lerer)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
> at
[jira] [Assigned] (CASSANDRA-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16400:
-
Assignee: Adam Holmberg
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 3.0.x, 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.0.x is broken in a different way, regardless of what characters are in the
> name:
> {noformat}
> cqlsh> create type ks.x ( v int );
> cqlsh> desc types;
> Keyspace system_schema
> --
>
> Keyspace system_auth
>
>
> Keyspace system
> ---
>
> Keyspace ks
> ---
> list[i] not a string for i in 0
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16400:
--
Authors: Adam Holmberg
Test and Documentation Plan: unit test expanded
Status: Patch Available (was: In Progress)
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Priority: Normal
> Fix For: 3.0.x, 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.0.x is broken in a different way, regardless of what characters are in the
> name:
> {noformat}
> cqlsh> create type ks.x ( v int );
> cqlsh> desc types;
> Keyspace system_schema
> --
>
> Keyspace system_auth
>
>
> Keyspace system
> ---
>
> Keyspace ks
> ---
> list[i] not a string for i in 0
> {noformat}
> 3.11 appears to handle everything properly.
--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier
[
https://issues.apache.org/jira/browse/CASSANDRA-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317488#comment-17317488
]
Adam Holmberg commented on CASSANDRA-16400:
---
The patch is based on my branch for CASSANDRA-16539 since it builds on a test
introduced there.
[patch|https://github.com/aholmberg/cassandra/pull/52]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16400-trunk]
> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Priority: Normal
> Fix For: 3.0.x, 4.0.x
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in
> do_describe
> self.describe_list(result)
> File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in
> position 1: ordinal not in range(128)
> {noformat}
> 3.0.x is broken in a different way, regardless of what characters are in the
> name:
> {noformat}
> cqlsh> create type ks.x ( v int );
> cqlsh> desc types;
> Keyspace system_schema
> --
>
> Keyspace system_auth
>
>
> Keyspace system
> ---
>
> Keyspace ks
> ---
> list[i] not a string for i in 0
> {noformat}
> 3.11 appears to handle everything properly.
--
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
