[jira] [Commented] (CASSANDRA-19105) Using Capture to save results in CQLSH with Tracing on incorrectly saves the trace details
[
https://issues.apache.org/jira/browse/CASSANDRA-19105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801060#comment-17801060
]
Brad Schoening commented on CASSANDRA-19105:
[~gautamg] Yes, but not an option. If you enable '{*}capture{*}' for query
output, you don't expect *trace* output to be sent there. So the behavior for
trace output should change to always go to stdio (which can be redirected at
the Linux shell).
> Using Capture to save results in CQLSH with Tracing on incorrectly saves the
> trace details
> --
>
> Key: CASSANDRA-19105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Gautam G
>Priority: Normal
>
> When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to
> avoid paging through output when you want to see the trace results. However,
> the trace results are also incorrectly captured to the output file.
> According to *Help Capture* (below), only the query result should be saved.
> The correct behavior should display the trace results and only capture the
> query results.
> {_}Help capture message{_}: Only query result output is captured.
> Errors and output from cqlsh-only commands will still be shown in the cqlsh
> session.
>
--
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-19105) Using Capture to save results in CQLSH with Tracing on incorrectly saves the trace details
[
https://issues.apache.org/jira/browse/CASSANDRA-19105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801057#comment-17801057
]
Gautam G commented on CASSANDRA-19105:
--
Got it [~bschoeni] . So, we plan provide an option where we only capture the
query output to the file and the trace output should be displayed in the shell.
Correct me if I have understood it wrong.
Thank you.
> Using Capture to save results in CQLSH with Tracing on incorrectly saves the
> trace details
> --
>
> Key: CASSANDRA-19105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Gautam G
>Priority: Normal
>
> When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to
> avoid paging through output when you want to see the trace results. However,
> the trace results are also incorrectly captured to the output file.
> According to *Help Capture* (below), only the query result should be saved.
> The correct behavior should display the trace results and only capture the
> query results.
> {_}Help capture message{_}: Only query result output is captured.
> Errors and output from cqlsh-only commands will still be shown in the cqlsh
> session.
>
--
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
Re: [PR] CASSANDRA-19223: Column type mapping error for timestamp type during … [cassandra-analytics]
frankgh commented on code in PR #28:
URL:
https://github.com/apache/cassandra-analytics/pull/28#discussion_r1437860156
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/TableSchema.java:
##
@@ -136,11 +136,11 @@ private static List>
getConverters(StructType
.map(fieldName -> {
if (fieldName.equals(ttlOption.columnName()))
{
- return
SqlToCqlTypeConverter.getIntegerConverter();
+ return SqlToCqlTypeConverter.integerConverter();
}
if (fieldName.equals(timestampOption.columnName()))
{
- return SqlToCqlTypeConverter.getLongConverter();
+ return
SqlToCqlTypeConverter.microsecondsTimestampConverter();
Review Comment:
timestamp is expected to be in microseconds
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-site updated (eef7824a6 -> fdaba11f5)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard eef7824a6 generate docs for 13ca47fe add 37300befe Change Summit's register button to watch videos add fdaba11f5 generate docs for 37300bef This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (eef7824a6) \ N -- N -- N refs/heads/asf-site (fdaba11f5) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/_/index.html | 4 +- .../4.1.0/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.0/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.1/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.1/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.2/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.2/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.3/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.3/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1/cassandra/tools/nodetool/bootstrap.html| 7 +- .../doc/4.1/cassandra/tools/nodetool/nodetool.html | 7 +- .../4.1/cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../managing/tools/nodetool/bootstrap.html | 9 ++- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 80 ++--- .../getting-started/mtlsauthenticators.html| 69 ++ .../managing/configuration/cass_yaml_file.html | 3 + .../managing/tools/nodetool/bootstrap.html | 8 +-- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 68 +- .../managing/tools/nodetool/bootstrap.html | 9 ++- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 80 ++--- .../stable/cassandra/tools/nodetool/bootstrap.html | 7 +- .../stable/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../getting-started/mtlsauthenticators.html| 69 ++ .../managing/configuration/cass_yaml_file.html | 3 + .../managing/tools/nodetool/bootstrap.html | 8 +-- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 68 +- content/search-index.js| 2 +- site-content/source/modules/ROOT/pages/index.adoc | 4 +- site-ui/build/ui-bundle.zip| Bin 4883726 -> 4883726 bytes 38 files changed, 629 insertions(+), 459 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18999:
Status: Ready to Commit (was: Changes Suggested)
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-18999) Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading patch version without Cassandra 3 nodes.
[
https://issues.apache.org/jira/browse/CASSANDRA-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801031#comment-17801031
]
Paulo Motta commented on CASSANDRA-18999:
-
I created CASSANDRA-19243 to have a wider review on removal of pre-4.0
compatibility code.
For this ticket, let's just merge the original 4.0/4.1/5.0 PRs fixing
{{Gossiper::hasMajorVersion3Nodes}} without removing pre-4.0 compatibility code
from 5.0:
I have prepared the patches for commit:
*
[cassandra-4.0|https://github.com/pauloricardomg/cassandra/tree/cassandra-4.0]
*
[cassandra-4.1|https://github.com/pauloricardomg/cassandra/tree/cassandra-4.1]
*
[cassandra-5.0|https://github.com/pauloricardomg/cassandra/tree/cassandra-5.0]
I've submitted a [devbranch
job|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2649/] for the
cassandra-5.0 branch but it seems ci-cassandra.a.o is unavailable.
I don't have circle environment setup, so I will wait until jenkins is back or
someone submits a circle job for cassandra-5.0 before committing this.
> Gossiper::hasMajorVersion3Nodes returns true when a cluster is upgrading
> patch version without Cassandra 3 nodes.
> -
>
> Key: CASSANDRA-18999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18999
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Isaac Reath
>Assignee: Isaac Reath
>Priority: Low
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When working on https://issues.apache.org/jira/browse/CASSANDRA-18968 we
> found that {{Gossiper::hasMajorVersion3Nodes}} will return true when the
> cluster is undergoing an upgrade from a patch version even if the cluster has
> no Cassandra 3 nodes in it.
> This can be reproduced by running this Gossiper test:
> {code:java}
> @Test
> public void
> testHasVersion3NodesShouldReturnFalseWhenNoVersion3NodesDetectedAndCassandra4UpgradeInProgress()
> throws Exception
> {
> Gossiper.instance.start(0);
> Gossiper.instance.expireUpgradeFromVersion();
> VersionedValue.VersionedValueFactory factory = new
> VersionedValue.VersionedValueFactory(null);
> EndpointState es = new EndpointState((HeartBeatState) null);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(CURRENT_VERSION.toString()));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.1"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.1"));
> es = new EndpointState((HeartBeatState) null);
> String previousPatchVersion = String.valueOf(CURRENT_VERSION.major) +
> '.' + (CURRENT_VERSION.minor) + '.' + (CURRENT_VERSION.patch - 1);
> es.addApplicationState(ApplicationState.RELEASE_VERSION,
> factory.releaseVersion(previousPatchVersion));
>
> Gossiper.instance.endpointStateMap.put(InetAddressAndPort.getByName("127.0.0.2"),
> es);
>
> Gossiper.instance.liveEndpoints.add(InetAddressAndPort.getByName("127.0.0.2"));
> assertFalse(Gossiper.instance.hasMajorVersion3Nodes());
> }
> {code}
> This seems to be because of
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L2360],
> where an upgrade in progress is possible but we are not upgrading from a
> lower family version (i.e from 4.1.1 to 4.1.2).
> From the comment in this function, it seems instead of the existing check, we
> would want to iterate over all known endpoints in gossip and return true if
> any of them do not have a version (similar to
> [https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236)
>
> |https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/gms/Gossiper.java#L227-L236).]
--
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-19243) Remove pre-4.0 compatibility code for 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801027#comment-17801027
]
Paulo Motta edited comment on CASSANDRA-19243 at 12/28/23 4:14 PM:
---
It was identified on CASSANDRA-18999 that {{Gossiper::hasMajorVersion3Nodes
}}was removed from trunk, effectively removing pre-4.0 compatibility from trunk.
This [PR|https://github.com/apache/cassandra/pull/3004] removes the method
{{Gossiper::hasMajorVersion3Nodes}} from cassandra-5.0 branch, which removes
pre-4.0 compatibility from 5.0.
In addition to reviewing the changes above, we need to ensure that no more
pre-4.0 compatibility code remains in 5.0+
Since the backward compatibility code will be removed, I propose adding a new
StartupCheck to prevent upgrade from version < 4.0 and a flag to override (if
this is not already there).
was (Author: paulo):
It was identified on CASSANDRA-18999 that {{Gossiper::hasMajorVersion3Nodes
}}was removed from trunk, effectively removing pre-4.0 compatibility from trunk.
This [PR|https://github.com/apache/cassandra/pull/3004] removes the method
{{Gossiper::hasMajorVersion3Nodes}} from cassandra-5.0 branch, which removes
pre-4.0 compatibility from 5.0.
In addition to reviewing the changes above, we need to ensure that no more
pre-4.0 compatibility code remains in 5.0+
Since the backward compatibility code will be removed, I propose adding a new
StartupCheck to prevent upgrade from version < 4.0 and a flag to override (if
this is not already there).
> Remove pre-4.0 compatibility code for 5.0
> -
>
> Key: CASSANDRA-19243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19243
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Paulo Motta
>Priority: Normal
>
> This is an umbrella ticket to discuss removing pre-4.0 compatibility code
> from 5.0, similar to CASSANDRA-12716 for 4.x.
> A few considerations:
> - Discuss/ratify removal of pre-compatibility code on dev mailing list
> - What compatibility features are being removed?
> - What upgrade tests are being removed ? Are they still relevant and can be
> reused?
> - Should upgrade from 3.x to 5.X fail on startup with an override flag?
> - Can/should we make it easier to deprecate/remove compatibility code for
> future major releases?
--
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-19243) Remove pre-4.0 compatibility code for 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801027#comment-17801027
]
Paulo Motta commented on CASSANDRA-19243:
-
It was identified on CASSANDRA-18999 that {{Gossiper::hasMajorVersion3Nodes
}}was removed from trunk, effectively removing pre-4.0 compatibility from trunk.
This [PR|https://github.com/apache/cassandra/pull/3004] removes the method
{{Gossiper::hasMajorVersion3Nodes}} from cassandra-5.0 branch, which removes
pre-4.0 compatibility from 5.0.
In addition to reviewing the changes above, we need to ensure that no more
pre-4.0 compatibility code remains in 5.0+
Since the backward compatibility code will be removed, I propose adding a new
StartupCheck to prevent upgrade from version < 4.0 and a flag to override (if
this is not already there).
> Remove pre-4.0 compatibility code for 5.0
> -
>
> Key: CASSANDRA-19243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19243
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Paulo Motta
>Priority: Normal
>
> This is an umbrella ticket to discuss removing pre-4.0 compatibility code
> from 5.0, similar to CASSANDRA-12716 for 4.x.
> A few considerations:
> - Discuss/ratify removal of pre-compatibility code on dev mailing list
> - What compatibility features are being removed?
> - What upgrade tests are being removed ? Are they still relevant and can be
> reused?
> - Should upgrade from 3.x to 5.X fail on startup with an override flag?
> - Can/should we make it easier to deprecate/remove compatibility code for
> future major releases?
--
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-19243) Remove pre-4.0 compatibility code for 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-19243: Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug Workflow) Issue Type: Improvement (was: Bug) > Remove pre-4.0 compatibility code for 5.0 > - > > Key: CASSANDRA-19243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19243 > Project: Cassandra > Issue Type: Improvement >Reporter: Paulo Motta >Priority: Normal > > This is an umbrella ticket to discuss removing pre-4.0 compatibility code > from 5.0, similar to CASSANDRA-12716 for 4.x. > A few considerations: > - Discuss/ratify removal of pre-compatibility code on dev mailing list > - What compatibility features are being removed? > - What upgrade tests are being removed ? Are they still relevant and can be > reused? > - Should upgrade from 3.x to 5.X fail on startup with an override flag? > - Can/should we make it easier to deprecate/remove compatibility code for > future major releases? -- 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-19243) Remove pre-4.0 compatibility code for 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-19243: Description: This is an umbrella ticket to discuss removing pre-4.0 compatibility code from 5.0, similar to CASSANDRA-12716 for 4.x. A few considerations: - Discuss/ratify removal of pre-compatibility code on dev mailing list - What compatibility features are being removed? - What upgrade tests are being removed ? Are they still relevant and can be reused? - Should upgrade from 3.x to 5.X fail on startup with an override flag? - Can/should we make it easier to deprecate/remove compatibility code for future major releases? was:TBD > Remove pre-4.0 compatibility code for 5.0 > - > > Key: CASSANDRA-19243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19243 > Project: Cassandra > Issue Type: Bug >Reporter: Paulo Motta >Priority: Normal > > This is an umbrella ticket to discuss removing pre-4.0 compatibility code > from 5.0, similar to CASSANDRA-12716 for 4.x. > A few considerations: > - Discuss/ratify removal of pre-compatibility code on dev mailing list > - What compatibility features are being removed? > - What upgrade tests are being removed ? Are they still relevant and can be > reused? > - Should upgrade from 3.x to 5.X fail on startup with an override flag? > - Can/should we make it easier to deprecate/remove compatibility code for > future major releases? -- 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] [Created] (CASSANDRA-19243) Remove pre-4.0 compatibility code for 5.0
Paulo Motta created CASSANDRA-19243: --- Summary: Remove pre-4.0 compatibility code for 5.0 Key: CASSANDRA-19243 URL: https://issues.apache.org/jira/browse/CASSANDRA-19243 Project: Cassandra Issue Type: Bug Reporter: Paulo Motta TBD -- 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
