[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832516#comment-17832516
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 3:37 AM:
--
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the [design|https://github.com/apache/cassandra/pull/3182/files] look
okay? Or, should I use a map-lookup to get type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
was (Author: JIRAUSER303038):
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the design look okay? Or, should I use a map-lookup to get
type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832516#comment-17832516
]
Arun Ganesh commented on CASSANDRA-19150:
-
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the design look okay? Or, should I use a map-lookup to get
type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19150:
Attachment: test_output_old.txt
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19150:
Attachment: test_output.txt
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832500#comment-17832500 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 3/30/24 9:23 PM: -- I rebased and ran a preliminary CI tests (skinny dev workflow but in private infra) and it seems some of the last changes broke two tests: ||h6. org.apache.cassandra.index.sai.functional.CompactionTest-_jdk11_x86_64 failures: 1|| || || ||h6. Class||h6. Method||h6. Output|| |h6. index.sai.functional.CompactionTest|h6. testAntiCompaction-_jdk11_x86_64|h6. Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1407) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1412) at org.apache.cassandra.index.sai.functional.CompactionTest.testAntiCompaction(CompactionTest.java:115) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) Caused by: java.lang.AssertionError: [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:531) at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:516) at org.apache.cassandra.index.sai.functional.CompactionTest.lambda$testAntiCompaction$1(CompactionTest.java:115) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)| ||h6. org.apache.cassandra.index.sai.functional.SnapshotTest-_jdk11_x86_64 failures: 1|| || || ||h6. Class||h6. Method||h6. Output|| |h6. index.sai.functional.SnapshotTest|h6. shouldTakeAndRestoreSnapshots-_jdk11_x86_64|h6. Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at
[jira] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832500#comment-17832500 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 3/30/24 9:22 PM: -- I rebased and ran a preliminary CI tests (skinny dev workflow but in private infra) and it seems some of the last changes broke two tests: ||h6. org.apache.cassandra.index.sai.functional.CompactionTest-_jdk11_x86_64 failures: 1|| || || ||h6. Class||h6. Method||h6. Output|| |h6. index.sai.functional.CompactionTest|h6. testAntiCompaction-_jdk11_x86_64|h6. Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1407) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1412) at org.apache.cassandra.index.sai.functional.CompactionTest.testAntiCompaction(CompactionTest.java:115) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) Caused by: java.lang.AssertionError: [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:531) at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:516) at org.apache.cassandra.index.sai.functional.CompactionTest.lambda$testAntiCompaction$1(CompactionTest.java:115) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)| ||h6. org.apache.cassandra.index.sai.functional.SnapshotTest-_jdk11_x86_64 failures: 1|| || || ||h6. Class||h6. Method||h6. Output|| |h6. index.sai.functional.SnapshotTest|h6. shouldTakeAndRestoreSnapshots-_jdk11_x86_64|h6. Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at
[jira] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832500#comment-17832500 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 3/30/24 9:20 PM: -- I rebased and ran a preliminary CI tests (skinny dev workflow but in private infra) and it seems some of the last changes broke two tests: ||org.apache.cassandra.index.sai.functional.CompactionTest-_jdk11_x86_64 failures: 1|| || || ||Class||Method||Output|| |index.sai.functional.CompactionTest|testAntiCompaction-_jdk11_x86_64|Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1407) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1412) at org.apache.cassandra.index.sai.functional.CompactionTest.testAntiCompaction(CompactionTest.java:115) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) Caused by: java.lang.AssertionError: [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:531) at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:516) at org.apache.cassandra.index.sai.functional.CompactionTest.lambda$testAntiCompaction$1(CompactionTest.java:115) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)| ||org.apache.cassandra.index.sai.functional.SnapshotTest-_jdk11_x86_64 failures: 1|| || || || ||Class||Method||Output||Duration|| |index.sai.functional.SnapshotTest|shouldTakeAndRestoreSnapshots-_jdk11_x86_64|Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
[jira] [Commented] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832500#comment-17832500 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - I rebased and ran a preliminary CI tests (skinny dev workflow but in private infra) and it seems some of the last changes broke two tests: ||org.apache.cassandra.index.sai.functional.CompactionTest-_jdk11_x86_64 failures: 1|| || || || ||Class||Method||Output||Duration|| |index.sai.functional.CompactionTest|testAntiCompaction-_jdk11_x86_64|Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1407) at org.apache.cassandra.cql3.CQLTester.waitForAssert(CQLTester.java:1412) at org.apache.cassandra.index.sai.functional.CompactionTest.testAntiCompaction(CompactionTest.java:115) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) Caused by: java.lang.AssertionError: [build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-4-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-2-big-SAI+aa+RowToToken.db, build/test/cassandra/data/cql_test_keyspace/table_testanticompaction_01-6216d570eebc11ee898565731b7624ca/nb-1-big-SAI+aa+RowToToken.db] expected:<2> but was:<3> at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:531) at org.apache.cassandra.index.sai.SAITester.verifyIndexFiles(SAITester.java:516) at org.apache.cassandra.index.sai.functional.CompactionTest.lambda$testAntiCompaction$1(CompactionTest.java:115) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)|16.015| ||org.apache.cassandra.index.sai.functional.SnapshotTest-_jdk11_x86_64 failures: 1|| || || || ||Class||Method||Output||Duration|| |index.sai.functional.SnapshotTest|shouldTakeAndRestoreSnapshots-_jdk11_x86_64|Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds.-org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.cassandra.cql3.CQLTester that uses java.lang.Runnable null within 15 seconds. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at
[jira] [Commented] (CASSANDRA-18130) Log hardware and container params during test runs to help troubleshoot intermittent failures
[
https://issues.apache.org/jira/browse/CASSANDRA-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832447#comment-17832447
]
Michael Semb Wever commented on CASSANDRA-18130:
this was the snippet that was briefly in during CASSANDRA-18594
{code}
// CASSANDRA-18130
def saveAgentReport() {
if (isCanonical()) {
//
// echo "Updating disk usage report…";
// sh """
// ( echo "" ;
// echo \$(date) ;
// echo "${JOB_NAME} ${BUILD_NUMBER} ${STAGE_NAME}" ;
// du -xm / 2>/dev/null | sort -rn | head -n 30 ;
// df -h ) | tee -a \$(date +"%Y%m%d%H%M")-disk-usage-stats.txt
// """
// copyToNightlies("*-disk-usage-stats.txt",
"cassandra/agents/${NODE_NAME}/disk-usage/")
// sh 'rm *-disk-usage-stats.txt'
}
}
{code}
> Log hardware and container params during test runs to help troubleshoot
> intermittent failures
> -
>
> Key: CASSANDRA-18130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18130
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> {color:#00}We’ve long had flakiness in our containerized ASF CI
> environment that we don’t see in circleci. The environment itself is both
> containerized and heterogenous, so there are differences in both the hardware
> environment and the software environment in which it executes. For reference,
> see:
> [https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#current-agents]{color}
> {color:#00} {color}
> {color:#00}We should log a variety of hardware, container, and software
> environment details to help get to the bottom of where some test failures may
> be occurring. As we don’t have shell access to the machines it’ll be easier
> to have this information logged / retrieved during test runs than to try and
> profile each host independently.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832369#comment-17832369 ] Maxwell Guo edited comment on CASSANDRA-19448 at 3/30/24 7:23 AM: -- Hi Sorry for the late reply. I was in a hurry recently so I was away for a while. [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. ||Heading 1||Heading 2|| |PR for trunk |[pr|https://github.com/apache/cassandra/pull/3215/]| And the ci are running ,will check if the they finished. ||Heading 1||Heading 2|| |java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/8102b770-a623-4417-a5ea-5c602b7e6949]| |java17|[java17|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/82eb1c09-ca27-46b0-996c-7d841e062423]| was (Author: maxwellguo): Hi [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. ||Heading 1||Heading 2|| |PR for trunk |[pr|https://github.com/apache/cassandra/pull/3215/]| And the ci are running ,will check if the they finished. ||Heading 1||Heading 2|| |java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/8102b770-a623-4417-a5ea-5c602b7e6949]| |java17|[java17|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/82eb1c09-ca27-46b0-996c-7d841e062423]| > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832409#comment-17832409 ] Maxwell Guo commented on CASSANDRA-19448: - The reason why I fixed it like this is because I want to make the rip time configurable in seconds, milliseconds, and microseconds level . I think microseconds is the upper limit because the upper limit of c* timestamp is this; Then the original method converts the timestamp to milliseconds by default see [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2761] and [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L498]. I feel that the timestamp granularity should be aligned with the timestamp of c*, and then the user granularity configuration can be selected for the rip time. [~brandon.williams][~tiagomlalves] WDYT ? > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832369#comment-17832369 ] Maxwell Guo edited comment on CASSANDRA-19448 at 3/30/24 7:16 AM: -- Hi [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. ||Heading 1||Heading 2|| |PR for trunk |[pr|https://github.com/apache/cassandra/pull/3215/]| And the ci are running ,will check if the they finished. ||Heading 1||Heading 2|| |java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/8102b770-a623-4417-a5ea-5c602b7e6949]| |java17|[java17|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/82eb1c09-ca27-46b0-996c-7d841e062423]| was (Author: maxwellguo): Hi [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. ||Heading 1||Heading 2|| |PR for trunk |https://github.com/apache/cassandra/pull/3215/| > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832369#comment-17832369 ] Maxwell Guo edited comment on CASSANDRA-19448 at 3/30/24 7:12 AM: -- Hi [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. ||Heading 1||Heading 2|| |PR for trunk |https://github.com/apache/cassandra/pull/3215/| was (Author: maxwellguo): Hi [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x. > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
