[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377057#comment-17377057 ] Berenguer Blasi commented on CASSANDRA-16621: - [~djanand] I am trying to run your branch on a different CI. It just needs some time to complete and the 1st attempt failed. Let's see what it does there... > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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-15281) help for clearsnapshot needs to be updated to indicate requirement for --all
[
https://issues.apache.org/jira/browse/CASSANDRA-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15281:
Status: Changes Suggested (was: Review In Progress)
> help for clearsnapshot needs to be updated to indicate requirement for --all
>
>
> Key: CASSANDRA-15281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15281
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 15281.trunk
>
>
> According to _CASSANDRA-13391_
> _nodetool clearsnapshot should require --all to clear all snapshots_
> But the help for clearsnapshot does not indicate the same.
> {code:java}
> [ec2-user@ip-10-0-2-238 ~]$ nodetool help clearsnapshot
> NAME nodetool clearsnapshot - Remove the snapshot with the given name from
> the given keyspaces. If no snapshotName is specified we will remove all
> snapshots{code}
> The help for clearsnapshot needs to be updated to indicate requirement for
> --all to remove all snapshots.
--
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-15281) help for clearsnapshot needs to be updated to indicate requirement for --all
[
https://issues.apache.org/jira/browse/CASSANDRA-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376962#comment-17376962
]
Ekaterina Dimitrova commented on CASSANDRA-15281:
-
Hi [~tdl-jturner],
Thank you for the patch. It seems CASSANDRA-15380 happened in the meanwhile and
the current description is
"_Remove the snapshot with the given name from the given keyspaces_". After
CASSANDRA-13391
calling ClearSnaphot without a snapshot name no longer deletes all snapshots.
Can you, please, update the description according to the latest available
options? I know this response comes pretty late so if you don't have the time
anymore, please, let me know, I will be happy to help.
> help for clearsnapshot needs to be updated to indicate requirement for --all
>
>
> Key: CASSANDRA-15281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15281
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 15281.trunk
>
>
> According to _CASSANDRA-13391_
> _nodetool clearsnapshot should require --all to clear all snapshots_
> But the help for clearsnapshot does not indicate the same.
> {code:java}
> [ec2-user@ip-10-0-2-238 ~]$ nodetool help clearsnapshot
> NAME nodetool clearsnapshot - Remove the snapshot with the given name from
> the given keyspaces. If no snapshotName is specified we will remove all
> snapshots{code}
> The help for clearsnapshot needs to be updated to indicate requirement for
> --all to remove all snapshots.
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376951#comment-17376951
]
Ekaterina Dimitrova commented on CASSANDRA-15663:
-
Should we port this also to 4.0.0 before the release(with the updated list of
words of course)?
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15281) help for clearsnapshot needs to be updated to indicate requirement for --all
[
https://issues.apache.org/jira/browse/CASSANDRA-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15281:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> help for clearsnapshot needs to be updated to indicate requirement for --all
>
>
> Key: CASSANDRA-15281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15281
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 15281.trunk
>
>
> According to _CASSANDRA-13391_
> _nodetool clearsnapshot should require --all to clear all snapshots_
> But the help for clearsnapshot does not indicate the same.
> {code:java}
> [ec2-user@ip-10-0-2-238 ~]$ nodetool help clearsnapshot
> NAME nodetool clearsnapshot - Remove the snapshot with the given name from
> the given keyspaces. If no snapshotName is specified we will remove all
> snapshots{code}
> The help for clearsnapshot needs to be updated to indicate requirement for
> --all to remove all snapshots.
--
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-14900) DigestMismatchException log messages should be at TRACE
[
https://issues.apache.org/jira/browse/CASSANDRA-14900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14900:
Status: Needs Reviewer (was: Review In Progress)
> DigestMismatchException log messages should be at TRACE
> ---
>
> Key: CASSANDRA-14900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Config
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 3.0.x, 3.11.x
>
>
> DigestMismatchException log messages should probably be at TRACE. These log
> messages about normal digest mismatches that include scary stacktraces:
> {noformat}
> DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-786225366477494582,
> 31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
> (943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
> at
> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {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-14900) DigestMismatchException log messages should be at TRACE
[
https://issues.apache.org/jira/browse/CASSANDRA-14900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14900:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> DigestMismatchException log messages should be at TRACE
> ---
>
> Key: CASSANDRA-14900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Config
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 3.0.x, 3.11.x
>
>
> DigestMismatchException log messages should probably be at TRACE. These log
> messages about normal digest mismatches that include scary stacktraces:
> {noformat}
> DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-786225366477494582,
> 31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
> (943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
> at
> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {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-14900) DigestMismatchException log messages should be at TRACE
[
https://issues.apache.org/jira/browse/CASSANDRA-14900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376865#comment-17376865
]
Ekaterina Dimitrova commented on CASSANDRA-14900:
-
I personally don't see a reason why this can be agreed in 4.0 but not good for
3.11 or 3.0.
Anyway, we need one more committer reviewer or maybe [~ifesdjeen] will have
some time to look at it again.
> DigestMismatchException log messages should be at TRACE
> ---
>
> Key: CASSANDRA-14900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Local/Config
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 3.0.x, 3.11.x
>
>
> DigestMismatchException log messages should probably be at TRACE. These log
> messages about normal digest mismatches that include scary stacktraces:
> {noformat}
> DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-786225366477494582,
> 31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
> (943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
> at
> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {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-15779) test org.apache.cassandra.config.DatabaseDescriptorRefTest#testDatabaseDescriptorRef fail when run with intellij ide
[ https://issues.apache.org/jira/browse/CASSANDRA-15779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376863#comment-17376863 ] Ekaterina Dimitrova commented on CASSANDRA-15779: - [~mck], this test looks stable to me. Do we still think we need this fix? > test > org.apache.cassandra.config.DatabaseDescriptorRefTest#testDatabaseDescriptorRef > fail when run with intellij ide > > > Key: CASSANDRA-15779 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15779 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Yadong Chen >Assignee: Yadong Chen >Priority: Low > Labels: test > > I run > org.apache.cassandra.config.DatabaseDescriptorRefTest#testDatabaseDescriptorRef > using ide intellij with mac > and it fails with following message: > Thread #13: AsyncAppender-Worker-ASYNC > Thread #12: Attach Listener > Thread #10: logback-1 > Thread #5: Monitor Ctrl-Break > Thread #4: Signal Dispatcher > Thread #3: Finalizer > Thread #2: Reference Handler > Thread #1: main > java.lang.AssertionError: thread started in clientInitialization > Expected :5 > Actual :8 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15067) MV tests need to wait for builds to start
[
https://issues.apache.org/jira/browse/CASSANDRA-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376858#comment-17376858
]
Ekaterina Dimitrova edited comment on CASSANDRA-15067 at 7/7/21, 9:55 PM:
--
Hey [~marcuse],
I started looking into the broader list of patches available and this one
grabbed my attention.
I think these tests are stable now in Jenkins and they were fixed in a
different way with other tickets by adding some timing.
Do you think we should close this one?
was (Author: e.dimitrova):
Hey [~marcuse],
I started looking into the broader list of patches available and this one
grabbed my attention.
I think these tests are stable now in Jenkins and they were fixed in a
different with other tickets by adding some timing.
Do you think we should close this one?
> MV tests need to wait for builds to start
> -
>
> Key: CASSANDRA-15067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15067
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Seen a few failures like these lately:
> https://circleci.com/gh/krummas/cassandra/1981#tests/containers/49
> https://circleci.com/gh/krummas/cassandra/1969#tests/containers/21
> where it looks like the {{self._wait_for_view("ks", "t_by_v")}} call happens
> before the {{system.view_builds_in_progress}} table has been populated and
> then doesn't wait at all
--
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-15067) MV tests need to wait for builds to start
[
https://issues.apache.org/jira/browse/CASSANDRA-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376858#comment-17376858
]
Ekaterina Dimitrova commented on CASSANDRA-15067:
-
Hey [~marcuse],
I started looking into the broader list of patches available and this one
grabbed my attention.
I think these tests are stable now in Jenkins and they were fixed in a
different with other tickets by adding some timing.
Do you think we should close this one?
> MV tests need to wait for builds to start
> -
>
> Key: CASSANDRA-15067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15067
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Seen a few failures like these lately:
> https://circleci.com/gh/krummas/cassandra/1981#tests/containers/49
> https://circleci.com/gh/krummas/cassandra/1969#tests/containers/21
> where it looks like the {{self._wait_for_view("ks", "t_by_v")}} call happens
> before the {{system.view_builds_in_progress}} table has been populated and
> then doesn't wait at all
--
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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-14162: Status: Patch Available (was: Review In Progress) > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-14162: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Status: Review In Progress (was: Patch Available) > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-16775) Reduce the log level on "expected" repair exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16775:
Test and Documentation Plan:
- new unit tests around abort functionality in ValidationTask
- new in-JVM dtests around log message severity through repair/validation errors
Status: Patch Available (was: In Progress)
[patch|https://github.com/apache/cassandra/pull/1104]
[Circle
J8|https://app.circleci.com/pipelines/github/maedhroz/cassandra/288/workflows/98e0b78d-ffbb-48df-832f-5acb4897f362]
[Circle
J11|https://app.circleci.com/pipelines/github/maedhroz/cassandra/288/workflows/5053fe0b-9aec-4167-ba08-3656cd6129d8]
The primary aim of this patch was to reduce the logging level from ERROR to
WARN for a number of exceptions that distract from the root causes of
repair/validation failures. Along the way, i.e. while writing and debugging the
new {{RepairErrorsTest}}, I discovered that we don't properly release off-heap
Merkle trees through remote validation errors. To make sure that the new tests
aren't flaky out of the box, I went ahead and fixed that as well.
> Reduce the log level on "expected" repair exceptions
>
>
> Key: CASSANDRA-16775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16775
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair, Observability/Logging
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> Many of the repair errors we typically see in the logs are redundant. Say for
> example that one node has an unreadable SSTable...we should log that fact at
> ERROR, but then the failing repairs due to that unreadable SSTable should be
> at WARN, making it easier to find the actual problem.
--
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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-14162: Status: Patch Available (was: Review In Progress) > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-14162: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[
https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376804#comment-17376804
]
Stefan Miklosovic edited comment on CASSANDRA-14162 at 7/7/21, 7:50 PM:
[~brandon.williams] would you mind to review please?
[https://github.com/apache/cassandra/pull/1103/files]
{code:java}
[21:28:09 ~]$ docker-shell-master-nodetool compactionstats -H
pending tasks: 3
id compaction type keyspace table
completed total unit progress
54a026b0-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 244.39
MB 709.18 MB bytes 34.46%
1b9c5b40-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 340.16
MB 710.4 MB bytes 47.88%
Active compaction remaining time : 0h13m55s
[21:28:12 ~]$ docker-shell-master-nodetool compactionhistory
Compaction History:
id keyspace_name columnfamily_name
compacted_atbytes_in bytes_out rows_merged
dddae0b0-df57-11eb-a591-43fc063264b7 system_schema tables
2021-07-07T21:16:44.219 3396 2716 {1:7, 4:1}
ddd0a780-df57-11eb-a591-43fc063264b7 system_schema columns
2021-07-07T21:16:44.152 6300 5798 {1:7, 4:1}
dd206a50-df57-11eb-a591-43fc063264b7 system_schema keyspaces
2021-07-07T21:16:42.997 669 381 {1:7, 4:1}
ce15b510-df57-11eb-a591-43fc063264b7 systemsstable_activity
2021-07-07T21:16:17.761 1492 354 {1:62, 2:6}
cdd8fa30-df57-11eb-a591-43fc063264b7 systemlocal
2021-07-07T21:16:17.363 5378 5160 {4:1}
cdcec100-df57-11eb-a591-43fc063264b7 systemsize_estimates
2021-07-07T21:16:17.296 4612836268 {1:4, 2:1, 3:1}
cdaf5220-df57-11eb-a591-43fc063264b7 system_auth
resource_role_permissons_index 2021-07-07T21:16:17.090 611 304 {1:4,
2:4, 3:3}
cd9672f0-df57-11eb-a591-43fc063264b7 system_auth role_permissions
2021-07-07T21:16:16.927 1013 522 {1:1, 4:1}
cbe3b9e0-df57-11eb-a591-43fc063264b7 system_schema views
2021-07-07T21:16:14.078 153 99{1:3, 2:1}
[21:49:44 ~]$ docker-shell-master-nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size
on disk
1625686746556 system_distributed parent_repair_history 0 bytes 13
bytes
1625686746556 system_distributed repair_history 0 bytes 13
bytes
1625686746556 keyspace1 counter1 0 bytes 847
bytes
1625686746556 keyspace1 standard1 1.5 GB2.31
GB
1625686746556 test test 0 bytes 872
bytes
1625686746556 system_authroles 0 bytes 5.14
KB
1625686746556 system_authrole_members 0 bytes 13
bytes
1625686746556 system_authresource_role_permissons_index 0 bytes 15.6
KB
1625686746556 system_authrole_permissions 0 bytes 15.75
KB
1625686746556 system_traces sessions 0 bytes 13
bytes
1625686746556 system_traces events 0 bytes 13
bytesTotal TrueDiskSpaceUsed: 1.5 GB
{code}
was (Author: stefan.miklosovic):
[~brandon.williams] would you mind to review please?
[https://github.com/apache/cassandra/pull/1103/files]
{code:java}
[21:28:09 ~]$ docker-shell-master-nodetool compactionstats -H
pending tasks: 3
id compaction type keyspace table
completed total unit progress
54a026b0-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 244.39
MB 709.18 MB bytes 34.46%
1b9c5b40-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 340.16
MB 710.4 MB bytes 47.88%
Active compaction remaining time : 0h13m55s
[21:28:12 ~]$ docker-shell-master-nodetool compactionhistory
Compaction History:
id keyspace_name columnfamily_name
compacted_atbytes_in bytes_out rows_merged
dddae0b0-df57-11eb-a591-43fc063264b7 system_schema tables
2021-07-07T21:16:44.219 3396 2716 {1:7, 4:1}
ddd0a780-df57-11eb-a591-43fc063264b7 system_schema columns
2021-07-07T21:16:44.152 6300 5798 {1:7, 4:1}
dd206a50-df57-11eb-a591-43fc063264b7 system_schema keyspaces
2021-07-07T21:16:42.997 669 381 {1:7, 4:1}
ce15b510-df57-11eb-a591-43fc063264b7 systemsstable_activity
2021-07-07T21:16:17.761 1492 354 {1:62, 2:6}
[jira] [Comment Edited] (CASSANDRA-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[
https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376804#comment-17376804
]
Stefan Miklosovic edited comment on CASSANDRA-14162 at 7/7/21, 7:36 PM:
[~brandon.williams] would you mind to review please?
[https://github.com/apache/cassandra/pull/1103/files]
{code:java}
[21:28:09 ~]$ docker-shell-master-nodetool compactionstats -H
pending tasks: 3
id compaction type keyspace table
completed total unit progress
54a026b0-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 244.39
MB 709.18 MB bytes 34.46%
1b9c5b40-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 340.16
MB 710.4 MB bytes 47.88%
Active compaction remaining time : 0h13m55s
[21:28:12 ~]$ docker-shell-master-nodetool compactionhistory
Compaction History:
id keyspace_name columnfamily_name
compacted_atbytes_in bytes_out rows_merged
dddae0b0-df57-11eb-a591-43fc063264b7 system_schema tables
2021-07-07T21:16:44.219 3396 2716 {1:7, 4:1}
ddd0a780-df57-11eb-a591-43fc063264b7 system_schema columns
2021-07-07T21:16:44.152 6300 5798 {1:7, 4:1}
dd206a50-df57-11eb-a591-43fc063264b7 system_schema keyspaces
2021-07-07T21:16:42.997 669 381 {1:7, 4:1}
ce15b510-df57-11eb-a591-43fc063264b7 systemsstable_activity
2021-07-07T21:16:17.761 1492 354 {1:62, 2:6}
cdd8fa30-df57-11eb-a591-43fc063264b7 systemlocal
2021-07-07T21:16:17.363 5378 5160 {4:1}
cdcec100-df57-11eb-a591-43fc063264b7 systemsize_estimates
2021-07-07T21:16:17.296 4612836268 {1:4, 2:1, 3:1}
cdaf5220-df57-11eb-a591-43fc063264b7 system_auth
resource_role_permissons_index 2021-07-07T21:16:17.090 611 304 {1:4,
2:4, 3:3}
cd9672f0-df57-11eb-a591-43fc063264b7 system_auth role_permissions
2021-07-07T21:16:16.927 1013 522 {1:1, 4:1}
cbe3b9e0-df57-11eb-a591-43fc063264b7 system_schema views
2021-07-07T21:16:14.078 153 99{1:3, 2:1}
{code}
was (Author: stefan.miklosovic):
PR
[https://github.com/apache/cassandra/pull/1103/files]
{code:java}
[21:28:09 ~]$ docker-shell-master-nodetool compactionstats -H
pending tasks: 3
id compaction type keyspace table
completed total unit progress
54a026b0-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 244.39
MB 709.18 MB bytes 34.46%
1b9c5b40-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 340.16
MB 710.4 MB bytes 47.88%
Active compaction remaining time : 0h13m55s
[21:28:12 ~]$ docker-shell-master-nodetool compactionhistory
Compaction History:
id keyspace_name columnfamily_name
compacted_atbytes_in bytes_out rows_merged
dddae0b0-df57-11eb-a591-43fc063264b7 system_schema tables
2021-07-07T21:16:44.219 3396 2716 {1:7, 4:1}
ddd0a780-df57-11eb-a591-43fc063264b7 system_schema columns
2021-07-07T21:16:44.152 6300 5798 {1:7, 4:1}
dd206a50-df57-11eb-a591-43fc063264b7 system_schema keyspaces
2021-07-07T21:16:42.997 669 381 {1:7, 4:1}
ce15b510-df57-11eb-a591-43fc063264b7 systemsstable_activity
2021-07-07T21:16:17.761 1492 354 {1:62, 2:6}
cdd8fa30-df57-11eb-a591-43fc063264b7 systemlocal
2021-07-07T21:16:17.363 5378 5160 {4:1}
cdcec100-df57-11eb-a591-43fc063264b7 systemsize_estimates
2021-07-07T21:16:17.296 4612836268 {1:4, 2:1, 3:1}
cdaf5220-df57-11eb-a591-43fc063264b7 system_auth
resource_role_permissons_index 2021-07-07T21:16:17.090 611 304 {1:4,
2:4, 3:3}
cd9672f0-df57-11eb-a591-43fc063264b7 system_auth role_permissions
2021-07-07T21:16:16.927 1013 522 {1:1, 4:1}
cbe3b9e0-df57-11eb-a591-43fc063264b7 system_schema views
2021-07-07T21:16:14.078 153 99{1:3, 2:1}
{code}
> Backport 7950 (Output of nodetool compactionstats and compactionhistory does
> not work well with long keyspace and column family names)
> --
>
> Key: CASSANDRA-14162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14162
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>
[jira] [Commented] (CASSANDRA-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376805#comment-17376805 ] Stefan Miklosovic commented on CASSANDRA-14162: --- https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/902/ > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[
https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376804#comment-17376804
]
Stefan Miklosovic edited comment on CASSANDRA-14162 at 7/7/21, 7:32 PM:
PR
[https://github.com/apache/cassandra/pull/1103/files]
{code:java}
[21:28:09 ~]$ docker-shell-master-nodetool compactionstats -H
pending tasks: 3
id compaction type keyspace table
completed total unit progress
54a026b0-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 244.39
MB 709.18 MB bytes 34.46%
1b9c5b40-df58-11eb-a591-43fc063264b7 Compaction keyspace1 standard1 340.16
MB 710.4 MB bytes 47.88%
Active compaction remaining time : 0h13m55s
[21:28:12 ~]$ docker-shell-master-nodetool compactionhistory
Compaction History:
id keyspace_name columnfamily_name
compacted_atbytes_in bytes_out rows_merged
dddae0b0-df57-11eb-a591-43fc063264b7 system_schema tables
2021-07-07T21:16:44.219 3396 2716 {1:7, 4:1}
ddd0a780-df57-11eb-a591-43fc063264b7 system_schema columns
2021-07-07T21:16:44.152 6300 5798 {1:7, 4:1}
dd206a50-df57-11eb-a591-43fc063264b7 system_schema keyspaces
2021-07-07T21:16:42.997 669 381 {1:7, 4:1}
ce15b510-df57-11eb-a591-43fc063264b7 systemsstable_activity
2021-07-07T21:16:17.761 1492 354 {1:62, 2:6}
cdd8fa30-df57-11eb-a591-43fc063264b7 systemlocal
2021-07-07T21:16:17.363 5378 5160 {4:1}
cdcec100-df57-11eb-a591-43fc063264b7 systemsize_estimates
2021-07-07T21:16:17.296 4612836268 {1:4, 2:1, 3:1}
cdaf5220-df57-11eb-a591-43fc063264b7 system_auth
resource_role_permissons_index 2021-07-07T21:16:17.090 611 304 {1:4,
2:4, 3:3}
cd9672f0-df57-11eb-a591-43fc063264b7 system_auth role_permissions
2021-07-07T21:16:16.927 1013 522 {1:1, 4:1}
cbe3b9e0-df57-11eb-a591-43fc063264b7 system_schema views
2021-07-07T21:16:14.078 153 99{1:3, 2:1}
{code}
was (Author: stefan.miklosovic):
[https://github.com/apache/cassandra/pull/1103/files]
> Backport 7950 (Output of nodetool compactionstats and compactionhistory does
> not work well with long keyspace and column family names)
> --
>
> Key: CASSANDRA-14162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14162
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.x
>
> Attachments: 14162-3.0.patch, Screenshot from 2018-01-11
> 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from
> 2018-01-11 01-02-51.png
>
>
> Colleagues have had issues with output of listsnapshots/compactionstats
> because of things with really long names. Mostly cosmetic but I see no reason
> we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've
> attached a patch and a bunch of images to show the relevant commands working
> as intended after applying the patch.
--
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-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-14162: -- Test and Documentation Plan: tested manually / visually Status: Patch Available (was: In Progress) [https://github.com/apache/cassandra/pull/1103/files] > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.x > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- 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-16761) New Cassandra Website and Documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-16761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16761: --- Change Category: Code Clarity Complexity: Normal Priority: High (was: Normal) Status: Open (was: Triage Needed) > New Cassandra Website and Documentation > --- > > Key: CASSANDRA-16761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16761 > Project: Cassandra > Issue Type: Epic > Components: Documentation/Website >Reporter: Anthony Grasso >Assignee: Anthony Grasso >Priority: High > Fix For: 4.0.x > > > This epic captures the work associated with the development of the new > Cassandra website and documentation. > Work to create the new website and documentation will be broken up as follows: > * Proof of concept - CASSANDRA-16029 > * Website concept and design - CASSANDRA-16115 > * Develop tooling to render new website and documentation - CASSANDRA-16066 > * Create website content that will be rendered by new tooling - > CASSANDRA-16762 > * Create Cassandra documentation content that will be rendered by new > tooling - CASSANDRA-16763 > It is expected that the new website and documentation will be in asciidoc > format and rendered using Antora. > Antora is purpose built for rendering versioned documentation to HTML. In > addition it allows rendering customisations via Java Script which may be > useful when rending the website. -- 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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376698#comment-17376698 ] Michael Semb Wever edited comment on CASSANDRA-16649 at 7/7/21, 6:56 PM: - CI full pipelines: - 3.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/] - 3.11 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/] - 4.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/] - trunk [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/] Results are looking good. was (Author: michaelsembwever): CI full pipelines: - 3.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/] - 3.11 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/] - 4.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/] - trunk [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/] > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-14325) Java executable check succeeds despite no java on PATH
[
https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376785#comment-17376785
]
Alexey Zotov commented on CASSANDRA-14325:
--
The patch looks good to me, however, I have two small comments:
1. Even though the patch's logic seems to be working perfectly well, I feel
the same can be achieved in a bit more compact way:
{code:java}
diff --git a/bin/cassandra.in.sh b/bin/cassandra.in.sh
index 58b4dd2896..5d13cdae70 100644
--- a/bin/cassandra.in.sh
+++ b/bin/cassandra.in.sh
@@ -95,7 +95,7 @@ if [ -n "$JAVA_HOME" ]; then
fi
done
else
-JAVA=java
+JAVA=`command -v java 2> /dev/null`
fi
if [ -z $JAVA ] ; then
{code}
If there is no _java_ executable available then _JAVA_ variable will be empty
and _if [ -z $JAVA ]_ condition will match to trigger the error.
2. I can see two more similar scripts and I believe they need to be updated as
well:
{code:java}
redhat/cassandra.in.sh
tools/bin/cassandra.in.sh
{code}
PS:
I'm not a project committer. I've just chimed in after seeing [~blerer]'s email
seeking for reviewers.
> Java executable check succeeds despite no java on PATH
> --
>
> Key: CASSANDRA-14325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14325
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: bin_cassandra.patch
>
>
> The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if
> JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The
> error message "_Unable to find java executable. Check JAVA_HOME and PATH
> environment variables._" will never be echoed on a PATH misconfiguration. If
> java isn't on the PATH the failure will instead occur on line 95 of
> cassandra-env.sh at the java version check.
> It would be better to check consistently for the java executable in one place
> in bin/cassandra. Also we don't want users to mistakenly think they have a
> java version problem when they in fact have a PATH problem.
> See proposed patch.
--
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-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376759#comment-17376759 ] Ekaterina Dimitrova commented on CASSANDRA-16714: - Fixed for 3.11. I didn't apply the patch and remove the ignore for 4.0 and trunk intentionally for now. I will come back to this after 4.0 GA. The class s not currently even in use in 4.0 and trunk. > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- 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-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16714: Fix Version/s: (was: 3.11.x) > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- 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-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16714: Since Version: 3.11.5 Source Control Link: https://github.com/apache/cassandra/commit/f3c2d3a0f9e1867f6976fabec35e4e02f5289c37 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.11.x > > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- 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
[cassandra] branch cassandra-4.0 updated (68af597 -> 71efaa0)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 68af597 Merge branch 'cassandra-3.11' into cassandra-4.0 add f3c2d3a Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet patch by Aleksandr Sorokoumov; reviewed by Ekaterina Dimitrova and Brandon Williams for CASSANDRA-16714 add 71efaa0 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit bf92a67fd3010950475e4d85dfaca9fa3d7e2199 Merge: 1207891 71efaa0 Author: Ekaterina Dimitrova AuthorDate: Wed Jul 7 13:49:32 2021 -0400 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (1207891 -> bf92a67)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1207891 Merge branch cassandra-4.0 into trunk add f3c2d3a Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet patch by Aleksandr Sorokoumov; reviewed by Ekaterina Dimitrova and Brandon Williams for CASSANDRA-16714 add 71efaa0 Merge branch 'cassandra-3.11' into cassandra-4.0 new bf92a67 Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (415a890 -> f3c2d3a)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 415a890 Merge branch cassandra-3.0 into cassandra-3.11 add f3c2d3a Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet patch by Aleksandr Sorokoumov; reviewed by Ekaterina Dimitrova and Brandon Williams for CASSANDRA-16714 No new revisions were added by this update. Summary of changes: test/unit/org/apache/cassandra/utils/SlidingTimeRateTest.java | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376745#comment-17376745
]
Andres de la Peña commented on CASSANDRA-15663:
---
[CI|https://app.circleci.com/pipelines/github/adelapena/cassandra/640/workflows/d3b015ed-7969-4009-a42f-351137729a7a]
for the {{cqlhandling}} patch looks good to me. If we were going to use that
approach we should also port the test added by CASSANDRA-16659.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376698#comment-17376698 ] Michael Semb Wever commented on CASSANDRA-16649: CI full pipelines: - 3.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/894/] - 3.11 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/895/] - 4.0 [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/898/] - trunk [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/899/] > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376693#comment-17376693 ] Benjamin Lerer commented on CASSANDRA-16703: Thanks a lot [~zoltanersek] and [~brandon.williams] > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0.1 > > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- 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-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Fix Version/s: 4.0.1 3.11.11 3.0.25 Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/eadb171d5dfa9de3ecc6dce47515d48771fa98f9 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into cassandra-3.0 at eadb171d5dfa9de3ecc6dce47515d48771fa98f9 and merged into cassandra-3.11, cassandra-4.0 and trunk > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0.1 > > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- 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
[cassandra] branch trunk updated (cdaa2da -> 1207891)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from cdaa2da Merge branch 'cassandra-4.0' into trunk add eadb171 Handle correctly the exceptions thrown by custom QueryHandler constructors add 415a890 Merge branch cassandra-3.0 into cassandra-3.11 add 68af597 Merge branch 'cassandra-3.11' into cassandra-4.0 add 1207891 Merge branch cassandra-4.0 into trunk No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/service/ClientState.java | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (fd9a282 -> 415a890)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fd9a282 Enable tombstone compactions when UNCHECKED_TOMBSTONE_COMPACTION_OPTION is set add eadb171 Handle correctly the exceptions thrown by custom QueryHandler constructors add 415a890 Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/service/ClientState.java | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (afcc0cc -> 68af597)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from afcc0cc Merge branch 'cassandra-4.0.0' into cassandra-4.0 add eadb171 Handle correctly the exceptions thrown by custom QueryHandler constructors add 415a890 Merge branch cassandra-3.0 into cassandra-3.11 add 68af597 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/service/ClientState.java | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (2d8b304 -> eadb171)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 2d8b304 Ninja fix comments saying mx4j defaults to 0.0.0.0 add eadb171 Handle correctly the exceptions thrown by custom QueryHandler constructors No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/service/ClientState.java | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Status: Patch Available (was: Review In Progress) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Status: Review In Progress (was: Patch Available) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376686#comment-17376686
]
Paulo Motta commented on CASSANDRA-16789:
-
Hi Abi,
Your initial working POC from
[PR#1046|https://github.com/apache/cassandra/pull/1046] looks great so far,
good job!
As we discussed in our last call let's make the following changes in order to
make this production-ready:
* Use Instant instead of String on {{SnapshotDetails.createdAt}} and
{{SnapshotDetails.expiresAt}}
* Rename {{SnapshotDetails}} -> {{SnapshotManifest}}, since a single keyspace
snapshot can have contain multiple table manifests
* Create new inner class {{SnapshotDetails}} on {{SnapshotManager}}, which
represents a set of {{SnapshotManifest}} of a given keyspace with the same name.
* Update SnapshotManager to use the following structure
{code:java}
class SnapshotManager {
ScheduledFuture cleanupTaskFuture;
Map activeSnapshots;
void start() {
populateActiveSnapshots();
cleanupTaskFuture =
scheduleWithFixedDelay(this::clearExpiredSnapshots, 0, 1, TimeUnit.MINUTES);
}
void addSnapshot(String name, SnapshotManifest manifest) {
// Create new SnapshotDetails if it's a new snapshot, otherwise add to
existing
}
void populateActiveSnapshots(){
// Read snapshots from disk and add it to activeSnapshots
}
void clearExpiredSnapshots() {
for (SnapshotDetails snapshot : activeSnapshots.values()) {
if (snapshot.isExpired()) {
logger.info("Clearing expired snapshot {}", snapshot);
snapshot.clear();
}
}
}
}
{code}
* Add unit test for each method of SnapshotManager on different scenarios
* Make {{ColumnFamilyStore.snapshotWithoutFlush}} add newly created snapshot
manifests to {{SnapshotManager}} (via {{SnapshotManager.addSnapshot}}
* Add dtest with the following structure:
** create snapshot with 1 minute TTL
** stop node
** start node
** Wait *up to* 1 minute for snapshot expiration
** Check snapshot is removed from disk
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
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-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16774: Fix Version/s: (was: 4.0.1) 4.0-rc3 > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc3, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- 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-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376677#comment-17376677 ] Caleb Rackliffe edited comment on CASSANDRA-16774 at 7/7/21, 4:21 PM: -- 4.0.0 back-port committed as https://github.com/apache/cassandra/commit/68bf950f72d20be9f31fd3f91669be7e28c050e4 (Also changed release to 4.0-rc3.) Thanks everyone! was (Author: maedhroz): 4.0.0 back-port committed as https://github.com/apache/cassandra/commit/68bf950f72d20be9f31fd3f91669be7e28c050e4 > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc3, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- 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-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376677#comment-17376677 ] Caleb Rackliffe commented on CASSANDRA-16774: - 4.0.0 back-port committed as https://github.com/apache/cassandra/commit/68bf950f72d20be9f31fd3f91669be7e28c050e4 > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- 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
[cassandra] branch cassandra-4.0.0 updated (6d16a53 -> 68bf950)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cassandra-4.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 6d16a53 Flaky ViewTest patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-16777 new 68bf950 BinLog does not close chronicle queue leaving this to GC to cleanup The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/binlog/BinLog.java | 2 ++ 2 files changed, 3 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: BinLog does not close chronicle queue leaving this to GC to cleanup
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new 68bf950 BinLog does not close chronicle queue leaving this to GC to cleanup new afcc0cc Merge branch 'cassandra-4.0.0' into cassandra-4.0 68bf950 is described below commit 68bf950f72d20be9f31fd3f91669be7e28c050e4 Author: David Capwell AuthorDate: Fri Jul 2 10:38:40 2021 -0700 BinLog does not close chronicle queue leaving this to GC to cleanup patch by David Capwell; reviewed by Caleb Rackliffe, Marcus Eriksson for CASSANDRA-16774 --- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/binlog/BinLog.java | 2 ++ 2 files changed, 3 insertions(+) diff --git a/CHANGES.txt b/CHANGES.txt index deb883e..a093977 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-rc3 + * BinLog does not close chronicle queue leaving this to GC to cleanup (CASSANDRA-16774) Merged from 3.11: Merged from 3.0: diff --git a/src/java/org/apache/cassandra/utils/binlog/BinLog.java b/src/java/org/apache/cassandra/utils/binlog/BinLog.java index f622954..63f74a3 100644 --- a/src/java/org/apache/cassandra/utils/binlog/BinLog.java +++ b/src/java/org/apache/cassandra/utils/binlog/BinLog.java @@ -169,7 +169,9 @@ public class BinLog implements Runnable shouldContinue = false; sampleQueue.put(NO_OP); binLogThread.join(); +appender.close(); appender = null; +queue.close(); queue = null; archiver.stop(); currentPaths.remove(path); - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e6a311f -> cdaa2da)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e6a311f Fix AbstractReadQuery::toCQLString not returning valid CQL new 68bf950 BinLog does not close chronicle queue leaving this to GC to cleanup new afcc0cc Merge branch 'cassandra-4.0.0' into cassandra-4.0 new cdaa2da Merge branch 'cassandra-4.0' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit cdaa2da91d8f411b7c144a20a0c6697b42c0febb Merge: e6a311f afcc0cc Author: Caleb Rackliffe AuthorDate: Wed Jul 7 11:15:29 2021 -0500 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376671#comment-17376671
]
Benedict Elliott Smith commented on CASSANDRA-15234:
So, I produced an initial proposal
[here|https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml]
in [this
comment|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17162342=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17162342].
It is not complete, but the shape of the idea is pretty clear, I think - it
would be good to get some initial feedback on this approach to grouping of
config options, as optimising the groups is a laborious job that there's no
point pursuing if it's otherwise unwelcome. We can no doubt bike shed those to
death as well, if we so choose.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376655#comment-17376655
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/7/21, 3:41 PM:
--
Reading back the thread here and reminding myself of what we discussed I guess
the next step is to hash out a proposal for the user list and get some feedback?
{quote}{quote} I'd personally prefer to hash out here for a week or so, to get
a good proposal to take to the user list, or a couple of competing proposals. I
find public engagements works best when there's a good case to
challenge/consider.
{quote}{quote}
was (Author: e.dimitrova):
Reading back the thread here and reminding myself of what we discussed I guess
the next step is to hash a proposal for the user list and get some feedback?
{quote}bq. I'd personally prefer to hash out here for a week or so, to get a
good proposal to take to the user list, or a couple of competing proposals. I
find public engagements works best when there's a good case to
challenge/consider.
{quote}
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376655#comment-17376655
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/7/21, 3:41 PM:
--
Reading back the thread here and reminding myself of what we discussed I guess
the next step is to hash out a proposal for the user list and get some feedback?
{quote}bq. I'd personally prefer to hash out here for a week or so, to get a
good proposal to take to the user list, or a couple of competing proposals. I
find public engagements works best when there's a good case to
challenge/consider.
{quote}
was (Author: e.dimitrova):
Reading back the thread here and reminding myself of what we discussed I guess
the next step is to hash out a proposal for the user list and get some feedback?
{quote}{quote} I'd personally prefer to hash out here for a week or so, to get
a good proposal to take to the user list, or a couple of competing proposals. I
find public engagements works best when there's a good case to
challenge/consider.
{quote}{quote}
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376655#comment-17376655
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Reading back the thread here and reminding myself of what we discussed I guess
the next step is to hash a proposal for the user list and get some feedback?
{quote}bq. I'd personally prefer to hash out here for a week or so, to get a
good proposal to take to the user list, or a couple of competing proposals. I
find public engagements works best when there's a good case to
challenge/consider.
{quote}
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376634#comment-17376634
]
Ekaterina Dimitrova edited comment on CASSANDRA-15663 at 7/7/21, 3:35 PM:
--
Thank you [~adelapena] for working on a patch. This seems to me IMHO like the
best idea at this moment which removes the confusion for the users why they see
DSE reserved keywords and also removes the dependency on drivers releases.
Let's see what the CI will show but I definitely like it at this point.
was (Author: e.dimitrova):
Thank you [~adelapena] for working on a patch. This seems like the best idea at
this moment which removes the confusion for the users why they see DSE reserved
keywords and also removes the dependency on drivers releases.
Let's see what the CI will show but I definitely like it at this point.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376653#comment-17376653 ] Ekaterina Dimitrova commented on CASSANDRA-16677: - Yes, I think this is one of the things that also Brandon found. But in my logs when the test fails this warning doesn't appear :( According to outbound.close, I saw it is invoked with _flushQueue=false_ Did you mean the test is not failing anymore at all if you use _AsyncPromise.isDone()_? Also, I wanted to confirm, did you trigger the warning in a specific way or the test just fails like that for you? > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0, 4.0-rc > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Status: Patch Available (was: Review In Progress) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Reviewers: Ekaterina Dimitrova, Vinay Chella (was: Vinay Chella) Status: Review In Progress (was: Patch Available) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14325: --- Status: Patch Available (was: Review In Progress) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: bin_cassandra.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14325: --- Reviewers: Brandon Williams, Benjamin Lerer (was: Benjamin Lerer, Brandon Williams) Brandon Williams, Benjamin Lerer (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: bin_cassandra.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16404: --- Status: Needs Reviewer (was: Review In Progress) > Provide a nodetool way of invalidating auth caches > -- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Sumanth Pasupuleti >Assignee: Alexey Zotov >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376645#comment-17376645 ] Ekaterina Dimitrova commented on CASSANDRA-16725: - Hey [~stefan.miklosovic], I just moved your patch to patch available as otherwise people won't see it and pick up for review. Also, based on our conversation in Slack I assigned version 4.1 to it. I understand that also you solved with [~paulo] the topic on why not virtual tables at this point. > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Test and Documentation Plan: [https://github.com/apache/cassandra/pull/1051/files] Status: Patch Available (was: Open) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Fix Version/s: 4.1 > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376634#comment-17376634
]
Ekaterina Dimitrova edited comment on CASSANDRA-15663 at 7/7/21, 3:13 PM:
--
Thank you [~adelapena] for working on a patch. This seems like the best idea at
this moment which removes the confusion for the users why they see DSE reserved
keywords and also removes the dependency on drivers releases.
Let's see what the CI will show but I definitely like it at this point.
was (Author: e.dimitrova):
Thank you [~adelapena] for working on a patch. This seems like the best idea at
this moment which removes the confusion for the users why they see DSE reserved
keywords and also doesn't rely on drivers releases.
Let's see what the CI will show but I definitely like it at this point.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376634#comment-17376634
]
Ekaterina Dimitrova commented on CASSANDRA-15663:
-
Thank you [~adelapena] for working on a patch. This seems like the best idea at
this moment which removes the confusion for the users why they see DSE reserved
keywords and also doesn't rely on drivers releases.
Let's see what the CI will show but I definitely like it at this point.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ion Olaru updated CASSANDRA-16787:
--
Description:
Getting error:
{code:java}
cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';
Using 3 child processes
Starting copy of users.user_credentials_by_email with columns [email,
la_duration].
Failed to make batch statement: Received an argument of invalid type for column
"la_duration". Expected: , Got: ; (DurationType arguments must be a Duration.)_
Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries
Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err
Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
0 rows imported from 1 files in 0.431 seconds (0 skipped).
{code}
*To Reproduce:*
{code:java}
CREATE KEYSPACE users WITH replication = {'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
{code}
create users.csv file with:
{code:java}
l...@la.com,8m26s482ms
{code}
Run:
{code:java}
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
{code}
was:
Getting error:
{code:java}
cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';
Using 3 child processes
Starting copy of users.user_credentials_by_email with columns [email,
la_duration].
Failed to make batch statement: Received an argument of invalid type for column
"la_duration". Expected: , Got: ; (DurationType arguments must be a Duration.)_
Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries
Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err
Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
0 rows imported from 1 files in 0.431 seconds (0 skipped).
{code}
*To Reproduce:*
{code:java}
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
{code}
create users.csv file with:
{code:java}
l...@la.com,8m26s482ms
{code}
Run:
{code:java}
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
{code}
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.1
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = {'class': 'NetworkTopologyStrategy',
> 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
> {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:
[jira] [Updated] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ion Olaru updated CASSANDRA-16787:
--
Description:
Getting error:
{code}
_cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';_
_Using 3 child processes_
_Starting copy of users.user_credentials_by_email with columns [email,
la_duration]._
_Failed to make batch statement: Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.)_
_Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries_
_Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err_
_Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
_0 rows imported from 1 files in 0.431 seconds (0 skipped)._
{code}
*To Reproduce:*
{code}
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
{code}
create users.csv file with:
{code}
l...@la.com,8m26s482ms
{code}
Run:
{code}
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
{code}
was:
Getting error:
_cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';_
_Using 3 child processes_
_Starting copy of users.user_credentials_by_email with columns [email,
la_duration]._
_Failed to make batch statement: Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.)_
_Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries_
_Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err_
_Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
_0 rows imported from 1 files in 0.431 seconds (0 skipped)._
*To Reproduce:*
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
create users.csv file with:
l...@la.com,8m26s482ms
Run:
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.1
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code}
> _cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';_
> _Using 3 child processes_
> _Starting copy of users.user_credentials_by_email with columns [email,
> la_duration]._
> _Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> _Failed to import 1 rows: TypeError - Received an argument of invalid type
> for column "la_duration". Expected: 'cassandra.cqltypes.DurationType'>, Got: ; (DurationType
> arguments must be a Duration.), given up without retries_
> _Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err_
> _Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
> _0 rows imported from 1 files in 0.431 seconds (0 skipped)._
> {code}
> *To Reproduce:*
> {code}
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code}
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
> {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-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ion Olaru updated CASSANDRA-16787:
--
Description:
Getting error:
{code:java}
cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';
Using 3 child processes
Starting copy of users.user_credentials_by_email with columns [email,
la_duration].
Failed to make batch statement: Received an argument of invalid type for column
"la_duration". Expected: , Got: ; (DurationType arguments must be a Duration.)_
Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries
Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err
Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
0 rows imported from 1 files in 0.431 seconds (0 skipped).
{code}
*To Reproduce:*
{code:java}
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
{code}
create users.csv file with:
{code:java}
l...@la.com,8m26s482ms
{code}
Run:
{code:java}
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
{code}
was:
Getting error:
{code}
_cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';_
_Using 3 child processes_
_Starting copy of users.user_credentials_by_email with columns [email,
la_duration]._
_Failed to make batch statement: Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.)_
_Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries_
_Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err_
_Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
_0 rows imported from 1 files in 0.431 seconds (0 skipped)._
{code}
*To Reproduce:*
{code}
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
{code}
create users.csv file with:
{code}
l...@la.com,8m26s482ms
{code}
Run:
{code}
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
{code}
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.1
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
> {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:
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376614#comment-17376614
]
Andres de la Peña commented on CASSANDRA-15663:
---
[Last CI
results|https://app.circleci.com/pipelines/github/adelapena/cassandra/638/workflows/9828c5f2-9207-44f7-bba7-d37e74842ac6]
for the upgraded and patched driver look better.
It seems that the ideal solution would be having PYTHON-1270, but it seems that
this isn't going to happen soon. I guess that if we are going to ship a patched
version of the driver we should also remove the DSE-only keywords, to avoid
problems like the one that can be seen with this example:
{code:java}
CREATE KEYSPACE node WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};
DESCRIBE KEYSPACES; # "node" is quoted
DESCRIBE KEYSPACE node; # Improper DESCRIBE command.
{code}
Alternatively, following the approach used in CASSANDRA-16659, we could try to
modify {{cqlhandling.py}} to just override the sets of keywords in the driver's
{{metadata}}. That way the driver's methods {{maybe_escape_name}},
{{protect_name}}, {{export_as_string}}, etc. would use the "injected" set of
reserved keywords. I gave it a go
[here|https://github.com/adelapena/cassandra/commit/9e94174e8a74cc11f6196e299eadf0d6565311b1],
and I'm trying to run CI on it.
To add some more confusion, the lists of keywords, reserved keywords and
unreserved keywords defined in the driver don't exactly match what is defined
in {{Parser.g}}, {{Lexer.g}} and {{ReservedKeywords.java}}. The driver assumes
that the reserved keywords are the difference between all the keywords and the
unreserved keywords (see
[here|https://github.com/Ge/python-driver/blob/master/cassandra/metadata.py#L90-L93]).
However, it seems that
[{{Lexer.g}}|https://github.com/apache/cassandra/blob/cassandra-3.11/src/antlr/Lexer.g#L58-L204]
contains some keywords that aren't included in neither the list of [unreserved
keywords defined in
{{Parser.g}}|https://github.com/apache/cassandra/blob/cassandra-3.11/src/antlr/Parser.g#L1640-L1687]
nor in the [list of reserved keywords defined in
{{ReservedKeywords.java}}|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/ReservedKeywords.java#L29-L92].
These keywords that aren't included in none of the reserved/unreserved sets
are {{varint}}, {{int}}, {{text}}, {{float}}, {{boolean}}, {{ttl}},
{{duration}}, {{ascii}}, {{smallint}}, {{uuid}}, {{distinct}}, {{bigint}},
{{json}}, {{blob}}, {{inet}}, {{timeuuid}}, {{varchar}}, {{timestamp}},
{{key}}, {{date}}, {{count}}, {{double}}, {{decimal}}, {{counter}}, {{cast}},
{{tinyint}}, {{writetime}} and {{time}}. The sets of keywords matching the
contents of those files would look [like
this|https://github.com/adelapena/cassandra/blob/b15a8bbb25a35f17617966aa5d4e056d3496a6f7/pylib/cqlshlib/cqlhandling.py#L26-L71].
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-16793) Add snapshot_before_compaction_ttl table option
[
https://issues.apache.org/jira/browse/CASSANDRA-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16793:
Authors: (was: Abuli Palagashvili)
Mentor: Paulo Motta
> Add snapshot_before_compaction_ttl table option
> ---
>
> Key: CASSANDRA-16793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16793
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This table option should take a human readable parameter (ie. 6h, 3days).
> When specified and {{snapshot_before_compaction: true}}, snapshots created
> on this table before compaction should use the specified TTL.
--
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-16793) Add snapshot_before_compaction_ttl table option
[
https://issues.apache.org/jira/browse/CASSANDRA-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta reassigned CASSANDRA-16793:
---
Assignee: Abuli Palagashvili (was: Paulo Motta)
> Add snapshot_before_compaction_ttl table option
> ---
>
> Key: CASSANDRA-16793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16793
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This table option should take a human readable parameter (ie. 6h, 3days).
> When specified and {{snapshot_before_compaction: true}}, snapshots created
> on this table before compaction should use the specified TTL.
--
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-16793) Add snapshot_before_compaction_ttl table option
[
https://issues.apache.org/jira/browse/CASSANDRA-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta reassigned CASSANDRA-16793:
---
Assignee: Abuli Palagashvili
Description: This table option should take a human readable parameter (ie.
6h, 3days). When specified and {{snapshot_before_compaction: true}}, snapshots
created on this table before compaction should use the specified TTL. (was:
This table option should take a human readable parameter (ie. 6h, 3days). When
specified and snapshot_before_compaction: true, snapshots created on this
table before compaction should use the specified TTL.)
> Add snapshot_before_compaction_ttl table option
> ---
>
> Key: CASSANDRA-16793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16793
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This table option should take a human readable parameter (ie. 6h, 3days).
> When specified and {{snapshot_before_compaction: true}}, snapshots created
> on this table before compaction should use the specified TTL.
--
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-16793) Add snapshot_before_compaction_ttl table option
[
https://issues.apache.org/jira/browse/CASSANDRA-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta reassigned CASSANDRA-16793:
---
Assignee: Paulo Motta (was: Abuli Palagashvili)
> Add snapshot_before_compaction_ttl table option
> ---
>
> Key: CASSANDRA-16793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16793
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> This table option should take a human readable parameter (ie. 6h, 3days).
> When specified and {{snapshot_before_compaction: true}}, snapshots created
> on this table before compaction should use the specified TTL.
--
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-16793) Add snapshot_before_compaction_ttl table option
Paulo Motta created CASSANDRA-16793: --- Summary: Add snapshot_before_compaction_ttl table option Key: CASSANDRA-16793 URL: https://issues.apache.org/jira/browse/CASSANDRA-16793 Project: Cassandra Issue Type: Sub-task Components: Local/Config Reporter: Paulo Motta This table option should take a human readable parameter (ie. 6h, 3days). When specified and snapshot_before_compaction: true, snapshots created on this table before compaction should use the specified TTL. -- 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-16792) Add snapshot_before_compaction_ttl configuration
Paulo Motta created CASSANDRA-16792: --- Summary: Add snapshot_before_compaction_ttl configuration Key: CASSANDRA-16792 URL: https://issues.apache.org/jira/browse/CASSANDRA-16792 Project: Cassandra Issue Type: Sub-task Reporter: Paulo Motta Assignee: Abuli Palagashvili This property should take a human readable parameter (ie. 6h, 3days). When specified and snapshot_before_compaction_ttl: true, snapshots created before compaction should use the specified TTL. -- 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-16791) Add auto_snapshot_ttl table option
[ https://issues.apache.org/jira/browse/CASSANDRA-16791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta reassigned CASSANDRA-16791: --- Component/s: Local/Config Mentor: Paulo Motta Assignee: Abuli Palagashvili > Add auto_snapshot_ttl table option > -- > > Key: CASSANDRA-16791 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16791 > Project: Cassandra > Issue Type: Sub-task > Components: Local/Config >Reporter: Paulo Motta >Assignee: Abuli Palagashvili >Priority: Normal > > This table option should take a human readable parameter (ie. 6h, 3days). > When specified and auto_snapshot: true, auto snapshots created on this table > should use the specified TTL. -- 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-16791) Add auto_snapshot_ttl table option
Paulo Motta created CASSANDRA-16791: --- Summary: Add auto_snapshot_ttl table option Key: CASSANDRA-16791 URL: https://issues.apache.org/jira/browse/CASSANDRA-16791 Project: Cassandra Issue Type: Sub-task Reporter: Paulo Motta This table option should take a human readable parameter (ie. 6h, 3days). When specified and auto_snapshot: true, auto snapshots created on this table should use the specified TTL. -- 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-16790) Add auto_snapshot_ttl configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16790:
Description: This property should take a human readable parameter (ie. 6h,
3days). When specified and {{auto_snapshot: true}}, auto snapshots created
should use the specified TTL. (was: This property should take a human
readable parameter (ie. 6h, 3days). When specified and {{auto_snapshot: true}},
snapshots created should use this default TTL.)
> Add auto_snapshot_ttl configuration
> ---
>
> Key: CASSANDRA-16790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16790
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This property should take a human readable parameter (ie. 6h, 3days). When
> specified and {{auto_snapshot: true}}, auto snapshots created should use the
> specified TTL.
--
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-16790) Add auto_snapshot_ttl configuration
Paulo Motta created CASSANDRA-16790:
---
Summary: Add auto_snapshot_ttl configuration
Key: CASSANDRA-16790
URL: https://issues.apache.org/jira/browse/CASSANDRA-16790
Project: Cassandra
Issue Type: Sub-task
Components: Local/Config
Reporter: Paulo Motta
Assignee: Abuli Palagashvili
This property should take a human readable parameter (ie. 6h, 3days). When
specified and {{auto_snapshot: true}}, snapshots created should use this
default TTL.
--
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-16789) Add TTL support to nodetool snapshots
Paulo Motta created CASSANDRA-16789:
---
Summary: Add TTL support to nodetool snapshots
Key: CASSANDRA-16789
URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
Project: Cassandra
Issue Type: Sub-task
Components: Tool/nodetool
Reporter: Paulo Motta
Assignee: Abuli Palagashvili
Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
not be lower than 1 minute.
The expiration date should be added to the snapshot manifest in ISO format.
A periodic thread should efficiently scan snapshots and automatically clear
those past expiration date. The periodicity of the scan thread should be 1
minute by default but be overridable via a system property.
The command {{nodetool listsnapshots}} should display the expiration date when
the snapshot contains a TTL.
--
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-14415) Performance regression in queries for distinct keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376550#comment-17376550
]
Benjamin Lerer commented on CASSANDRA-14415:
+1 on my side. [~benedict] and [~KurtG] already gave there +1 too.
I will rebase the patches and run CI.
> Performance regression in queries for distinct keys
> ---
>
> Key: CASSANDRA-14415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14415
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Normal
> Labels: performance
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Running Cassandra 3.0.16, we observed a major performance regression
> affecting {{SELECT DISTINCT keys}}-style queries against certain tables.
> Based on some investigation (guided by some helpful feedback from Benjamin on
> the dev list), we tracked the regression down to two problems.
> * One is that Cassandra was reading more data from disk than was necessary
> to satisfy the query. This was fixed under CASSANDRA-10657 in a later 3.x
> release.
> * If the fix for CASSANDRA-10657 is incorporated, the other is this code
> snippet in {{RebufferingInputStream}}:
> {code:java}
> @Override
> public int skipBytes(int n) throws IOException
> {
> if (n < 0)
> return 0;
> int requested = n;
> int position = buffer.position(), limit = buffer.limit(), remaining;
> while ((remaining = limit - position) < n)
> {
> n -= remaining;
> buffer.position(limit);
> reBuffer();
> position = buffer.position();
> limit = buffer.limit();
> if (position == limit)
> return requested - n;
> }
> buffer.position(position + n);
> return requested;
> }
> {code}
> The gist of it is that to skip bytes, the stream needs to read those bytes
> into memory then throw them away. In our tests, we were spending a lot of
> time in this method, so it looked like the chief drag on performance.
> We noticed that the subclass of {{RebufferingInputStream}} in use for our
> queries, {{RandomAccessReader}} (over compressed sstables), implements a
> {{seek()}} method. Overriding {{skipBytes()}} in it to use {{seek()}}
> instead was sufficient to fix the performance regression.
> The performance difference is significant for tables with large values. It's
> straightforward to evaluate with very simple key-value tables, e.g.:
> {{CREATE TABLE testtable (key TEXT PRIMARY KEY, value BLOB);}}
> We did some basic experimentation with the following variations (all in a
> single-node 3.11.2 cluster with off-the-shelf settings running on a dev
> workstation):
> * small values (1 KB, 100,000 entries), somewhat larger values (25 KB,
> 10,000 entries), and much larger values (1 MB, 10,000 entries);
> * compressible data (a single byte repeated) and uncompressible data (output
> from {{openssl rand $bytes}}); and
> * with and without sstable compression. (With compression, we use
> Cassandra's defaults.)
> The difference is most conspicuous for tables with large, uncompressible data
> and sstable decompression (which happens to describe the use case that
> triggered our investigation). It is smaller but still readily apparent for
> tables with effective compression. For uncompressible data without
> compression enabled, there is no appreciable difference.
> Here's what the performance looks like without our patch for the 1-MB entries
> (times in seconds, five consecutive runs for each data set, all exhausting
> the results from a {{SELECT DISTINCT key FROM ...}} query with a page size of
> 24):
> {noformat}
> working on compressible
> 5.21180510521
> 5.10270500183
> 5.22311806679
> 4.6732840538
> 4.84219098091
> working on uncompressible_uncompressed
> 55.0423607826
> 0.769015073776
> 0.850513935089
> 0.713396072388
> 0.62596988678
> working on uncompressible
> 413.292617083
> 231.345913887
> 449.524993896
> 425.135111094
> 243.469946861
> {noformat}
> and with the fix:
> {noformat}
> working on compressible
> 2.86733293533
> 1.24895811081
> 1.108907938
> 1.12742400169
> 1.04647302628
> working on uncompressible_uncompressed
> 56.4146180153
> 0.895509958267
> 0.922824144363
> 0.772884130478
> 0.731923818588
> working on uncompressible
> 64.4587619305
> 1.81325793266
> 1.52577018738
> 1.41769099236
> 1.60442209244
> {noformat}
> The long initial runs for the uncompressible data presumably come from
> repeatedly hitting the disk. In contrast to the runs without the fix, the
> initial runs seem to be effective at warming the page cache (as lots of data
> is skipped, so the data
[jira] [Updated] (CASSANDRA-14415) Performance regression in queries for distinct keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14415:
---
Reviewers: Benedict Elliott Smith, Benjamin Lerer, Benjamin Lerer (was:
Benedict Elliott Smith, Benjamin Lerer)
Benedict Elliott Smith, Benjamin Lerer, Benjamin Lerer (was:
Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> Performance regression in queries for distinct keys
> ---
>
> Key: CASSANDRA-14415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14415
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Normal
> Labels: performance
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Running Cassandra 3.0.16, we observed a major performance regression
> affecting {{SELECT DISTINCT keys}}-style queries against certain tables.
> Based on some investigation (guided by some helpful feedback from Benjamin on
> the dev list), we tracked the regression down to two problems.
> * One is that Cassandra was reading more data from disk than was necessary
> to satisfy the query. This was fixed under CASSANDRA-10657 in a later 3.x
> release.
> * If the fix for CASSANDRA-10657 is incorporated, the other is this code
> snippet in {{RebufferingInputStream}}:
> {code:java}
> @Override
> public int skipBytes(int n) throws IOException
> {
> if (n < 0)
> return 0;
> int requested = n;
> int position = buffer.position(), limit = buffer.limit(), remaining;
> while ((remaining = limit - position) < n)
> {
> n -= remaining;
> buffer.position(limit);
> reBuffer();
> position = buffer.position();
> limit = buffer.limit();
> if (position == limit)
> return requested - n;
> }
> buffer.position(position + n);
> return requested;
> }
> {code}
> The gist of it is that to skip bytes, the stream needs to read those bytes
> into memory then throw them away. In our tests, we were spending a lot of
> time in this method, so it looked like the chief drag on performance.
> We noticed that the subclass of {{RebufferingInputStream}} in use for our
> queries, {{RandomAccessReader}} (over compressed sstables), implements a
> {{seek()}} method. Overriding {{skipBytes()}} in it to use {{seek()}}
> instead was sufficient to fix the performance regression.
> The performance difference is significant for tables with large values. It's
> straightforward to evaluate with very simple key-value tables, e.g.:
> {{CREATE TABLE testtable (key TEXT PRIMARY KEY, value BLOB);}}
> We did some basic experimentation with the following variations (all in a
> single-node 3.11.2 cluster with off-the-shelf settings running on a dev
> workstation):
> * small values (1 KB, 100,000 entries), somewhat larger values (25 KB,
> 10,000 entries), and much larger values (1 MB, 10,000 entries);
> * compressible data (a single byte repeated) and uncompressible data (output
> from {{openssl rand $bytes}}); and
> * with and without sstable compression. (With compression, we use
> Cassandra's defaults.)
> The difference is most conspicuous for tables with large, uncompressible data
> and sstable decompression (which happens to describe the use case that
> triggered our investigation). It is smaller but still readily apparent for
> tables with effective compression. For uncompressible data without
> compression enabled, there is no appreciable difference.
> Here's what the performance looks like without our patch for the 1-MB entries
> (times in seconds, five consecutive runs for each data set, all exhausting
> the results from a {{SELECT DISTINCT key FROM ...}} query with a page size of
> 24):
> {noformat}
> working on compressible
> 5.21180510521
> 5.10270500183
> 5.22311806679
> 4.6732840538
> 4.84219098091
> working on uncompressible_uncompressed
> 55.0423607826
> 0.769015073776
> 0.850513935089
> 0.713396072388
> 0.62596988678
> working on uncompressible
> 413.292617083
> 231.345913887
> 449.524993896
> 425.135111094
> 243.469946861
> {noformat}
> and with the fix:
> {noformat}
> working on compressible
> 2.86733293533
> 1.24895811081
> 1.108907938
> 1.12742400169
> 1.04647302628
> working on uncompressible_uncompressed
> 56.4146180153
> 0.895509958267
> 0.922824144363
> 0.772884130478
> 0.731923818588
> working on uncompressible
> 64.4587619305
> 1.81325793266
> 1.52577018738
> 1.41769099236
> 1.60442209244
> {noformat}
> The long initial runs for the uncompressible data presumably come from
> repeatedly hitting the disk. In contrast to the runs without
[jira] [Updated] (CASSANDRA-14415) Performance regression in queries for distinct keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14415:
---
Reviewers: Benedict Elliott Smith, Benjamin Lerer, Kurt Greaves (was:
Benedict Elliott Smith, Benjamin Lerer)
> Performance regression in queries for distinct keys
> ---
>
> Key: CASSANDRA-14415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14415
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Normal
> Labels: performance
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Running Cassandra 3.0.16, we observed a major performance regression
> affecting {{SELECT DISTINCT keys}}-style queries against certain tables.
> Based on some investigation (guided by some helpful feedback from Benjamin on
> the dev list), we tracked the regression down to two problems.
> * One is that Cassandra was reading more data from disk than was necessary
> to satisfy the query. This was fixed under CASSANDRA-10657 in a later 3.x
> release.
> * If the fix for CASSANDRA-10657 is incorporated, the other is this code
> snippet in {{RebufferingInputStream}}:
> {code:java}
> @Override
> public int skipBytes(int n) throws IOException
> {
> if (n < 0)
> return 0;
> int requested = n;
> int position = buffer.position(), limit = buffer.limit(), remaining;
> while ((remaining = limit - position) < n)
> {
> n -= remaining;
> buffer.position(limit);
> reBuffer();
> position = buffer.position();
> limit = buffer.limit();
> if (position == limit)
> return requested - n;
> }
> buffer.position(position + n);
> return requested;
> }
> {code}
> The gist of it is that to skip bytes, the stream needs to read those bytes
> into memory then throw them away. In our tests, we were spending a lot of
> time in this method, so it looked like the chief drag on performance.
> We noticed that the subclass of {{RebufferingInputStream}} in use for our
> queries, {{RandomAccessReader}} (over compressed sstables), implements a
> {{seek()}} method. Overriding {{skipBytes()}} in it to use {{seek()}}
> instead was sufficient to fix the performance regression.
> The performance difference is significant for tables with large values. It's
> straightforward to evaluate with very simple key-value tables, e.g.:
> {{CREATE TABLE testtable (key TEXT PRIMARY KEY, value BLOB);}}
> We did some basic experimentation with the following variations (all in a
> single-node 3.11.2 cluster with off-the-shelf settings running on a dev
> workstation):
> * small values (1 KB, 100,000 entries), somewhat larger values (25 KB,
> 10,000 entries), and much larger values (1 MB, 10,000 entries);
> * compressible data (a single byte repeated) and uncompressible data (output
> from {{openssl rand $bytes}}); and
> * with and without sstable compression. (With compression, we use
> Cassandra's defaults.)
> The difference is most conspicuous for tables with large, uncompressible data
> and sstable decompression (which happens to describe the use case that
> triggered our investigation). It is smaller but still readily apparent for
> tables with effective compression. For uncompressible data without
> compression enabled, there is no appreciable difference.
> Here's what the performance looks like without our patch for the 1-MB entries
> (times in seconds, five consecutive runs for each data set, all exhausting
> the results from a {{SELECT DISTINCT key FROM ...}} query with a page size of
> 24):
> {noformat}
> working on compressible
> 5.21180510521
> 5.10270500183
> 5.22311806679
> 4.6732840538
> 4.84219098091
> working on uncompressible_uncompressed
> 55.0423607826
> 0.769015073776
> 0.850513935089
> 0.713396072388
> 0.62596988678
> working on uncompressible
> 413.292617083
> 231.345913887
> 449.524993896
> 425.135111094
> 243.469946861
> {noformat}
> and with the fix:
> {noformat}
> working on compressible
> 2.86733293533
> 1.24895811081
> 1.108907938
> 1.12742400169
> 1.04647302628
> working on uncompressible_uncompressed
> 56.4146180153
> 0.895509958267
> 0.922824144363
> 0.772884130478
> 0.731923818588
> working on uncompressible
> 64.4587619305
> 1.81325793266
> 1.52577018738
> 1.41769099236
> 1.60442209244
> {noformat}
> The long initial runs for the uncompressible data presumably come from
> repeatedly hitting the disk. In contrast to the runs without the fix, the
> initial runs seem to be effective at warming the page cache (as lots of data
> is skipped, so the data that's read can fit in memory), so
[jira] [Updated] (CASSANDRA-16788) BLOG - Changelog #8 July 2021
[ https://issues.apache.org/jira/browse/CASSANDRA-16788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16788: --- Status: Review In Progress (was: Patch Available) > BLOG - Changelog #8 July 2021 > - > > Key: CASSANDRA-16788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc3, 4.0 > > > Draft by [~Calico] - [C* Blog: Cassandra Changelog > #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. > Highlights: > * Apache Cassandra 4.0-rc2 released > * say hello to our Google Summer of Code intern > * new community intro to Cassandra videos -- 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-16788) BLOG - Changelog #8 July 2021
[ https://issues.apache.org/jira/browse/CASSANDRA-16788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16788: -- Test and Documentation Plan: # Confirm section headers are not prefixed with hashes. # Confirm that listing in the [Blog home|https://cassandra.apache.org/blog/] displays the first paragraph instead of the header image. # Verify that embedded videos/tweets render correctly. # Verify that all hyperlinks are working. Status: Patch Available (was: In Progress) PR #62 submitted ready for staging – https://github.com/apache/cassandra-website/pull/62 > BLOG - Changelog #8 July 2021 > - > > Key: CASSANDRA-16788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc3, 4.0 > > > Draft by [~Calico] - [C* Blog: Cassandra Changelog > #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. > Highlights: > * Apache Cassandra 4.0-rc2 released > * say hello to our Google Summer of Code intern > * new community intro to Cassandra videos -- 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-16788) BLOG - Changelog #8 July 2021
[ https://issues.apache.org/jira/browse/CASSANDRA-16788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-16788: --- Labels: pull-request-available (was: ) > BLOG - Changelog #8 July 2021 > - > > Key: CASSANDRA-16788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc3, 4.0 > > > Draft by [~Calico] - [C* Blog: Cassandra Changelog > #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. > Highlights: > * Apache Cassandra 4.0-rc2 released > * say hello to our Google Summer of Code intern > * new community intro to Cassandra videos -- 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-16788) BLOG - Changelog #8 July 2021
[ https://issues.apache.org/jira/browse/CASSANDRA-16788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16788: -- Change Category: Semantic Complexity: Normal Fix Version/s: 4.0 4.0-rc3 Reviewers: Erick Ramirez, Michael Semb Wever Status: Open (was: Triage Needed) > BLOG - Changelog #8 July 2021 > - > > Key: CASSANDRA-16788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0-rc3, 4.0 > > > Draft by [~Calico] - [C* Blog: Cassandra Changelog > #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. > Highlights: > * Apache Cassandra 4.0-rc2 released > * say hello to our Google Summer of Code intern > * new community intro to Cassandra videos -- 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-16788) BLOG - Changelog #8 July 2021
Erick Ramirez created CASSANDRA-16788: - Summary: BLOG - Changelog #8 July 2021 Key: CASSANDRA-16788 URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Erick Ramirez Assignee: Erick Ramirez Draft by [~Calico] - [C* Blog: Cassandra Changelog #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. Highlights: * Apache Cassandra 4.0-rc2 released * say hello to our Google Summer of Code intern * new community intro to Cassandra videos -- 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-16788) BLOG - Changelog #8 July 2021
[ https://issues.apache.org/jira/browse/CASSANDRA-16788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16788: -- Authors: Chris Thornett (was: Erick Ramirez) > BLOG - Changelog #8 July 2021 > - > > Key: CASSANDRA-16788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16788 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > > Draft by [~Calico] - [C* Blog: Cassandra Changelog > #8|https://docs.google.com/document/d/1aL-1C2ckMYvT9ch8pQUsAik_uA5SohAiI2POe4BvE20/edit?usp=sharing]. > Highlights: > * Apache Cassandra 4.0-rc2 released > * say hello to our Google Summer of Code intern > * new community intro to Cassandra videos -- 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-16677) Fix flaky ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376305#comment-17376305
]
Berenguer Blasi commented on CASSANDRA-16677:
-
The problem comes from trying to flush against an already closed connecttion.
Adding some stacks for future reference:
{noformat}
[junit-timeout] INFO [Messaging-EventLoop-3-7] 2021-07-06 12:17:23,858
InboundConnectionInitiator.java:464 -
/127.0.0.1:7012(/127.0.0.1:49576)->/127.0.0.1:7012-LARGE_MESSAGES-6cbecdc7
messaging connection established, version = 12, framing = LZ4, encryption =
encrypted(factory=openssl;protocol=TLSv1.3;cipher=TLS_AES_128_GCM_SHA256)
[junit-timeout] INFO [main] 2021-07-06 12:17:23,865
InboundConnectionInitiator.java:127 - Listening on address: (/127.0.0.1:17012),
nic: lo, encryption: encrypted(openssl)
[junit-timeout] INFO [main] 2021-07-06 12:17:23,865
InboundConnectionInitiator.java:127 - Listening on address: (/127.0.0.1:7012),
nic: lo, encryption: optionally encrypted(openssl)
[junit-timeout] WARN
[Messaging-OUT-/127.0.0.1:7012->/127.0.0.1:7012-LARGE_MESSAGES] 2021-07-06
12:17:23,868 OutboundConnection.java:488 -
/127.0.0.1:7012->/127.0.0.1:7012-LARGE_MESSAGES-[no-channel] dropping message
of type _TEST_1 due to error
[junit-timeout] org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException:
This output stream is in an unsafe state after an asynchronous flush failed
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:201)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:230)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
[junit-timeout] at
org.apache.cassandra.net.AsyncMessageOutputPlus.close(AsyncMessageOutputPlus.java:110)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$LargeMessageDelivery.doRun(OutboundConnection.java:986)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$Delivery.run(OutboundConnection.java:687)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$LargeMessageDelivery.run(OutboundConnection.java:955)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.lang.Thread.run(Thread.java:748)
[junit-timeout] Caused by: io.netty.handler.ssl.SslClosedEngineException:
SSLEngine closed already
[junit-timeout] at
io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:854)
[junit-timeout] at
io.netty.handler.ssl.SslHandler.wrapAndFlush(SslHandler.java:811)
[junit-timeout] at
io.netty.handler.ssl.SslHandler.flush(SslHandler.java:792)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:742)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:728)
[junit-timeout] at
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:125)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:765)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1071)
[junit-timeout] at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
[junit-timeout] at
io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[junit-timeout] at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[junit-timeout] ... 2 common frames omitted
{noformat}
{noformat}
[junit-timeout] org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException:
The channel this output stream was writing to has been closed
[junit-timeout] at
[jira] [Comment Edited] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375977#comment-17375977
]
Jogesh Anand edited comment on CASSANDRA-16621 at 7/7/21, 6:04 AM:
---
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the
[circle-ci|https://circleci.com/api/v1.1/project/github/djanand/cassandra/3/output/104/0?file=true=60deafb9c3492162b60b9b5e-0-build%2F58BCD97C]
tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
-When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.-
-This leads me to believe that the build on circle-ci is using a different
version of driver than local.-
ps: I'm using the default .circleci/config.yml
was (Author: djanand):
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the
[circle-ci|https://circleci.com/api/v1.1/project/github/djanand/cassandra/3/output/104/0?file=true=60deafb9c3492162b60b9b5e-0-build%2F58BCD97C]
tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.
This leads me to believe that the build on circle-ci is using a different
version of driver than local.
ps: I'm using the default .circleci/config.yml
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
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
