[jira] (CASSANDRA-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-19018 ]
Caleb Rackliffe deleted comment on CASSANDRA-19018:
-
was (Author: maedhroz):
[~adelapena] Read repair is enabled again
[here|https://github.com/maedhroz/cassandra/pull/15/commits]. I was incorrectly
sending an empty static row to the coordinator when resolution was required.
Now I think all that remains is short-read protection for post-RFP filtering...
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> result_details.tar-1.gz, result_details.tar.gz
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
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] (CASSANDRA-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-19018 ]
Caleb Rackliffe deleted comment on CASSANDRA-19018:
-
was (Author: maedhroz):
I think I may have found the missing link. While RFP is still broken around
short reads, SAI at the local level might be hiding range tombstones. I've
managed to get the multi-node Harry test passing in extended runs
[here|https://github.com/maedhroz/cassandra/pull/15/commits]. Paging and
read-repair are disabled here to avoid the potential RFP problems, and statics
are disabled, but I should now be able to add back statics and read-repair and
get clean runs. More on that shortly...
UPDATE: I've been able to add static indexing back without failure. At this
point, only read repair and paging are disabled, so attacking the RFP issues is
probably next.
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> result_details.tar-1.gz, result_details.tar.gz
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
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
(cassandra-website) branch asf-staging updated (dbcfb73a -> 1812a909)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard dbcfb73a generate docs for a1ebc6a8 new 1812a909 generate docs for a1ebc6a8 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 (dbcfb73a) \ N -- N -- N refs/heads/asf-staging (1812a909) 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. 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: site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Description:
CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
which enables Cassandra to support either password and mTLS-authenticated
connections.
As an operator, it would be useful to know which connections are mTLS
authenticated, and which are password authenticated, as a possible mode of
operation is migrating users from one from of authentication to another. It
would also be useful to know if that if authentication attempts are failing
which mode of authentication is unsuccessful.
Proposing to add the following:
* Add a {{mode: string}} and {{metadata: map}} to
{{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
{{metadata}} map (e.g. this can include the extracted {{identity}} from a
client certificate for {{mtls}} authentication).
* Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
added to existing output to maintain compatibility, much like
{{-client-options}} did.
* Update {{system_views.clients}} to include columns for these new fields.
* Add new metrics to {{{}ClientMetrics{}}}:
** Track authentication success and failures by mode. (Note: The metrics
present by authentication mode scope are contextual based on the Authenticator
used (e.g. only {{scope=Password}} will be present for
{{{}PasswordAuthenticator{}}})
{noformat}
Existing:
org.apache.cassandra.metrics:name=AuthSuccess,type=Client
org.apache.cassandra.metrics:name=AuthFailure,type=Client
New:
org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
{noformat}
*
** Track connection counts by mode:
{noformat}
Existing:
org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
(previously deprecated but still maintained)
New:
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
{noformat}
*
** A metric to track encrypted vs. non-encrypted connections:
{noformat}
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
{noformat}
was:
CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
which enables Cassandra to support either password and mTLS-authenticated
connections.
As an operator, it would be useful to know which connections are mTLS
authenticated, and which are password authenticated, as a possible mode of
operation is migrating users from one from of authentication to another. It
would also be useful to know if that if authentication attempts are failing
which mode of authentication is unsuccessful.
Proposing to add the following:
* Add a {{mode: string}} and {{metadata: map}} to
{{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
{{metadata}} map (e.g. this can include the extracted {{identity}} from a
client certificate for {{mtls}} authentication).
* Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
added to existing output to maintain compatibility, much like
{{-client-options}} did.
* Update {{system_views.clients}} to include columns for these new fields.
* Add new metrics to {{{}ClientMetrics{}}}:
** Track authentication success and failures by mode. (Note: The metrics
present by authentication mode scope are contextual based on the Authenticator
used (e.g. only {{scope=Password}} will be present for
{{{}PasswordAuthenticator{}}})
{noformat}
Existing:
org.apache.cassandra.metrics:name=AuthSuccess,type=Client
org.apache.cassandra.metrics:name=AuthFailure,type=Client
New:
org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
{noformat}
*
** Track connection counts by mode:
{noformat}
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815515#comment-17815515
]
Andy Tolbert commented on CASSANDRA-19366:
--
Thank you [~smiklosovic] and [~frankgh] for reviewing! Attached is a test run
from the latest commit
([ea6e2fd|https://github.com/apache/cassandra/pull/3085/commits/ea6e2fdc1db13996248e8f4ea9ce4dad34d85e23])
[^CASSANDRA-19366-trunk-6_ci_summary.html][^CASSANDRA-19366-trunk-1_test_results.tgz]which
came back clean except for
{{org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest#updateTest-_jdk11}}
which should be fixed by [CASSANDRA-19168].
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
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-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-6_ci_summary.html
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
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-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results-1.tgz
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
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-19369 Use XXHash32 for digest calculation of SSTables [cassandra-analytics]
yifan-c commented on code in PR #38:
URL:
https://github.com/apache/cassandra-analytics/pull/38#discussion_r1482390314
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java:
##
@@ -128,12 +128,13 @@ public class BulkSparkConf implements Serializable
protected boolean useOpenSsl;
protected int ringRetryCount;
protected final Set blockedInstances;
+protected final DigestTypeOption digestTypeOption;
public BulkSparkConf(SparkConf conf, Map options)
{
this.conf = conf;
Optional sidecarPortFromOptions =
MapUtils.getOptionalInt(options, WriterOptions.SIDECAR_PORT.name(), "sidecar
port");
-this.userProvidedSidecarPort = sidecarPortFromOptions.isPresent() ?
sidecarPortFromOptions.get() : getOptionalInt(SIDECAR_PORT).orElse(-1);
+this.userProvidedSidecarPort = sidecarPortFromOptions.orElseGet(() ->
getOptionalInt(SIDECAR_PORT).orElse(-1));
Review Comment:
nit: ternary operator reads better than orElseGet
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/common/Digest.java:
##
@@ -19,25 +19,13 @@
package org.apache.cassandra.spark.common;
-import java.security.MessageDigest;
-import java.util.Base64;
-
-public final class MD5Hash
+/**
+ * Interface that represents a checksum digest
Review Comment:
nit: checksum kind of equals to digest. It is repeat like "I have two animal
cats". Checksum can be removed
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/DigestTypeOption.java:
##
@@ -0,0 +1,60 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.cassandra.spark.bulkwriter;
+
+import org.apache.cassandra.spark.utils.DigestProvider;
+import org.apache.cassandra.spark.utils.MD5DigestProvider;
+import org.apache.cassandra.spark.utils.XXHash32DigestProvider;
+
+/**
+ * Represents the user-provided digest type configuration to be used to
validate SSTable files during bulk writes
+ */
+public enum DigestTypeOption
+{
+/**
+ * Represents an MD5 digest type option. This option is supported for
legacy reasons, but its use
+ * is strongly discouraged.
+ */
+MD5
+{
+@Override
+DigestProvider provider()
+{
+return new MD5DigestProvider();
+}
+},
+
+/**
+ * Represents an xxhash32 digest type option
+ */
+XXHASH32
+{
+@Override
+DigestProvider provider()
+{
+return new XXHash32DigestProvider();
+}
+};
+
+/**
+ * @return the provider for the configured digest type
+ */
+abstract DigestProvider provider();
Review Comment:
How about extracting out as an interface? And implement the interface in the
enum. Potentially, one cannot change the source and supply a different impl.
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/RecordWriter.java:
##
@@ -400,4 +403,23 @@ private StreamSession createStreamSession(TaskContext
taskContext)
LOGGER.info("[{}] Creating stream session for range={}",
taskContext.partitionId(), tokenRange);
return new StreamSession(writerContext, getStreamId(taskContext),
tokenRange, failureHandler);
}
+
+/**
+ * Functional interface that helps with supplying {@link SSTableWriter}
instances.
+ */
+public interface SSTableWriterSupplier
Review Comment:
nit: supplier by convention takes no parameter. It is the factory here.
SSTableWriterFactory wdyt?
--
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
[jira] [Updated] (CASSANDRA-19378) JMXStandardsTest fails when running with codecoverage
[
https://issues.apache.org/jira/browse/CASSANDRA-19378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Yan updated CASSANDRA-19378:
-
Source Control Link: https://github.com/apache/cassandra/pull/3092
> JMXStandardsTest fails when running with codecoverage
> -
>
> Key: CASSANDRA-19378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19378
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
>
> JMXStandardsTest is added in unit test since 4.1. I recently run this test
> with codecoverage and it fails:
> {code:java}
> ant codecoverage -Dtaskname=testsome
> -Dtest.name=org.apache.cassandra.tools.JMXStandardsTest {code}
> {code:java}
> [junit-timeout] - ---
> [junit-timeout] Testcase:
> interfaces(org.apache.cassandra.tools.JMXStandardsTest): FAILED
> [junit-timeout] Errors detected while validating MBeans [junit-timeout] Error
> at signature parameter; type java.lang.invoke.MethodHandles.Lookup is not in
> the supported set of types, method method 'private static boolean[]
> org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
> [junit-timeout] Error at signature parameter; type java.lang.Class is not in
> the supported set of types, method method 'private static boolean[]
> org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
> [junit-timeout] junit.framework.AssertionFailedError: Errors detected while
> validating MBeans [junit-timeout] Error at signature parameter; type
> java.lang.invoke.MethodHandles.Lookup is not in the supported set of types,
> method method 'private static boolean[]
> org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
> [junit-timeout] Error at signature parameter; type java.lang.Class is not in
> the supported set of types, method method 'private static boolean[]
> org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
> [junit-timeout] at
> org.apache.cassandra.tools.JMXStandardsTest.interfaces(JMXStandardsTest.java:156)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> This `$jacocoInit` method was included in the test, which should be excluded
>
--
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-19378) JMXStandardsTest fails when running with codecoverage
Yuqi Yan created CASSANDRA-19378:
Summary: JMXStandardsTest fails when running with codecoverage
Key: CASSANDRA-19378
URL: https://issues.apache.org/jira/browse/CASSANDRA-19378
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Yuqi Yan
Assignee: Yuqi Yan
JMXStandardsTest is added in unit test since 4.1. I recently run this test with
codecoverage and it fails:
{code:java}
ant codecoverage -Dtaskname=testsome
-Dtest.name=org.apache.cassandra.tools.JMXStandardsTest {code}
{code:java}
[junit-timeout] - --- [junit-timeout]
Testcase: interfaces(org.apache.cassandra.tools.JMXStandardsTest): FAILED
[junit-timeout] Errors detected while validating MBeans [junit-timeout] Error
at signature parameter; type java.lang.invoke.MethodHandles.Lookup is not in
the supported set of types, method method 'private static boolean[]
org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
[junit-timeout] Error at signature parameter; type java.lang.Class is not in
the supported set of types, method method 'private static boolean[]
org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
[junit-timeout] junit.framework.AssertionFailedError: Errors detected while
validating MBeans [junit-timeout] Error at signature parameter; type
java.lang.invoke.MethodHandles.Lookup is not in the supported set of types,
method method 'private static boolean[]
org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
[junit-timeout] Error at signature parameter; type java.lang.Class is not in
the supported set of types, method method 'private static boolean[]
org.apache.cassandra.service.StorageServiceMBean.$jacocoInit(java.lang.invoke.MethodHandles$Lookup,java.lang.String,java.lang.Class)'
[junit-timeout] at
org.apache.cassandra.tools.JMXStandardsTest.interfaces(JMXStandardsTest.java:156)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
This `$jacocoInit` method was included in the test, which should be excluded
--
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-19377] Startup Validation Failures when Checking Sidecar Connectivity (Analytics) [cassandra-analytics]
5 closed pull request #22: [CASSANDRA-19377] Startup Validation Failures when Checking Sidecar Connectivity (Analytics) URL: https://github.com/apache/cassandra-analytics/pull/22 -- 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
[jira] [Commented] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5.2
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815462#comment-17815462 ] Francisco Guerrero commented on CASSANDRASC-101: 4.5.3 was recently released, we should evaluate if we want to move to that version instead. > Upgrade Vert.x version in Sidecar to 4.5.2 > -- > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5 Vert.x version. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-19377: -- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-analytics/commit/d61e44f78fa4ba5ec395e1e39c507d666fddefd1 (was: https://github.com/apache/cassandra-analytics/pull/22) Resolution: Fixed Status: Resolved (was: Ready to Commit) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > Fix For: NA > > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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
(cassandra-analytics) branch trunk updated: CASSANDRA-19377 Startup Validation Failures when Checking Sidecar Connectivity
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git
The following commit(s) were added to refs/heads/trunk by this push:
new d61e44f CASSANDRA-19377 Startup Validation Failures when Checking
Sidecar Connectivity
d61e44f is described below
commit d61e44f78fa4ba5ec395e1e39c507d666fddefd1
Author: Yuriy Semchyshyn
AuthorDate: Wed Nov 29 17:49:29 2023 -0600
CASSANDRA-19377 Startup Validation Failures when Checking Sidecar
Connectivity
patch by Yuriy Semchyshyn; reviewed by Francisco Guerrero, Yifan Cai for
CASSANDRA-19377
---
CHANGES.txt | 1 +
.../java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java | 7 +++
.../org/apache/cassandra/spark/bulkwriter/CassandraContext.java | 5 +++--
.../java/org/apache/cassandra/spark/data/CassandraDataLayer.java | 5 +++--
.../apache/cassandra/spark/validation/CassandraValidation.java| 8
.../org/apache/cassandra/spark/validation/SidecarValidation.java | 8
scripts/build-sidecar.sh | 2 +-
7 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index a6578b8..e0ff584 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.0.0
+ * Startup Validation Failures when Checking Sidecar Connectivity
(CASSANDRA-19377)
* No longer need to synchronize on Schema.instance after Cassandra 4.0.12
(CASSANDRA-19351)
* Upgrade to Cassandra 4.0.12 and remove RowBufferMode and BatchSize options
(CASSANDRA-19334)
* Improve logging for bulk writes and on task failures (CASSANDRA-19331)
diff --git
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java
index 1a16ec3..022c1db 100644
---
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java
+++
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkSparkConf.java
@@ -80,6 +80,7 @@ public class BulkSparkConf implements Serializable
public static final int DEFAULT_SIDECAR_REQUEST_RETRIES = 10;
public static final long DEFAULT_SIDECAR_REQUEST_RETRY_DELAY_MILLIS =
TimeUnit.SECONDS.toMillis(1L);
public static final long DEFAULT_SIDECAR_REQUEST_MAX_RETRY_DELAY_MILLIS =
TimeUnit.SECONDS.toMillis(60L);
+public static final int DEFAULT_SIDECAR_REQUEST_TIMEOUT_SECONDS = 300;
public static final int DEFAULT_COMMIT_BATCH_SIZE = 10_000;
public static final int DEFAULT_RING_RETRY_COUNT = 3;
public static final int DEFAULT_SSTABLE_DATA_SIZE_IN_MIB = 160;
@@ -96,6 +97,7 @@ public class BulkSparkConf implements Serializable
public static final String SIDECAR_REQUEST_RETRIES =
SETTING_PREFIX + "sidecar.request.retries";
public static final String SIDECAR_REQUEST_RETRY_DELAY_MILLIS =
SETTING_PREFIX + "sidecar.request.retries.delay.milliseconds";
public static final String SIDECAR_REQUEST_MAX_RETRY_DELAY_MILLIS =
SETTING_PREFIX + "sidecar.request.retries.max.delay.milliseconds";
+public static final String SIDECAR_REQUEST_TIMEOUT_SECONDS =
SETTING_PREFIX + "sidecar.request.timeout.seconds";
public static final String SKIP_CLEAN =
SETTING_PREFIX + "job.skip_clean";
public static final String USE_OPENSSL =
SETTING_PREFIX + "use_openssl";
public static final String RING_RETRY_COUNT=
SETTING_PREFIX + "ring_retry_count";
@@ -384,6 +386,11 @@ public class BulkSparkConf implements Serializable
return getLong(SIDECAR_REQUEST_MAX_RETRY_DELAY_MILLIS,
DEFAULT_SIDECAR_REQUEST_MAX_RETRY_DELAY_MILLIS);
}
+public int getSidecarRequestTimeoutSeconds()
+{
+return getInt(SIDECAR_REQUEST_TIMEOUT_SECONDS,
DEFAULT_SIDECAR_REQUEST_TIMEOUT_SECONDS);
+}
+
public int getHttpConnectionTimeoutMs()
{
return getInt(HTTP_CONNECTION_TIMEOUT,
DEFAULT_HTTP_CONNECTION_TIMEOUT);
diff --git
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraContext.java
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraContext.java
index eacaf89..08fb79b 100644
---
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraContext.java
+++
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraContext.java
@@ -111,8 +111,9 @@ public class CassandraContext implements
StartupValidatable, Closeable
@Override
public void startupValidate()
{
-StartupValidator.instance().register(new
SidecarValidation(sidecarClient));
-StartupValidator.instance().register(new
[jira] [Updated] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-102: -- Resolution: Duplicate Status: Resolved (was: Open) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-19377: -- Status: Ready to Commit (was: Review In Progress) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815461#comment-17815461 ] Francisco Guerrero commented on CASSANDRA-19377: +1 on the patch. Thanks! > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-102: -- Status: Patch Available (was: Ready to Commit) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-102: -- Status: Open (was: Patch Available) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-19377: -- Reviewers: Francisco Guerrero, Yifan Cai Status: Review In Progress (was: Patch Available) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815460#comment-17815460 ] Yifan Cai commented on CASSANDRA-19377: --- +1 on the patch! > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] [Assigned] (CASSANDRA-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai reassigned CASSANDRA-19377: - Assignee: Yuriy Semchyshyn > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[jira] [Updated] (CASSANDRA-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Semchyshyn updated CASSANDRA-19377: - Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) This is a follow-up issue to https://issues.apache.org/jira/browse/CASSANDRASC-86 that has already been committed. The reviewed patch is here: https://github.com/apache/cassandra-analytics/pull/22. The successful build is here: https://app.circleci.com/pipelines/github/5/cassandra-analytics/49/workflows/8ac5b581-e015-4c7f-b1ed-1b5bd9f4976c. > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815459#comment-17815459 ] Yifan Cai commented on CASSANDRASC-102: --- The patch is for analytics. Please create the ticket under Cassandra project, to be consistent with the current convention. > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRA-19377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Semchyshyn updated CASSANDRA-19377: - Authors: Yuriy Semchyshyn Test and Documentation Plan: https://app.circleci.com/pipelines/github/5/cassandra-analytics/49/workflows/8ac5b581-e015-4c7f-b1ed-1b5bd9f4976c Status: Patch Available (was: Open) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRA-19377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19377) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
Yuriy Semchyshyn created CASSANDRA-19377: Summary: Startup Validation Failures when Checking Sidecar Connectivity (Analytics) Key: CASSANDRA-19377 URL: https://issues.apache.org/jira/browse/CASSANDRA-19377 Project: Cassandra Issue Type: Improvement Components: Analytics Library Reporter: Yuriy Semchyshyn We have experienced repeated startup validation failures caused by Sidecar health checks for some jobs with a large number of Spark executors. It is worth increasing the overall timeout for Sidecar health checks from current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-102: -- Status: Ready to Commit (was: Review In Progress) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815457#comment-17815457 ] Yifan Cai commented on CASSANDRASC-102: --- +1 on the patch > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Reviewers: Francisco Guerrero, Stefan Miklosovic (was: Stefan Miklosovic)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
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
(cassandra-website) branch asf-staging updated (8b48b060 -> dbcfb73a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 8b48b060 generate docs for a1ebc6a8 new dbcfb73a generate docs for a1ebc6a8 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 (8b48b060) \ N -- N -- N refs/heads/asf-staging (dbcfb73a) 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. 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: site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815448#comment-17815448 ] Francisco Guerrero commented on CASSANDRASC-102: +1 the patch looks good to me > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-102: --- Reviewers: Francisco Guerrero Status: Review In Progress (was: Patch Available) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] [Assigned] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero reassigned CASSANDRASC-102: -- Assignee: Yuriy Semchyshyn > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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
(cassandra-website) branch asf-staging updated (ebd3b488 -> 8b48b060)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard ebd3b488 generate docs for a1ebc6a8 new 8b48b060 generate docs for a1ebc6a8 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 (ebd3b488) \ N -- N -- N refs/heads/asf-staging (8b48b060) 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. 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: site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19333: Reviewers: Bret McGuire (was: Bret McGuire, Ekaterina Dimitrova) > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19333: Status: Needs Committer (was: Review In Progress) > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5.2
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-101: - Summary: Upgrade Vert.x version in Sidecar to 4.5.2 (was: Upgrade Vert.x version in Sidecar to 4.5) > Upgrade Vert.x version in Sidecar to 4.5.2 > -- > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5 Vert.x version. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Semchyshyn updated CASSANDRASC-102: - Source Control Link: https://github.com/apache/cassandra-analytics/pull/22 > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815412#comment-17815412 ] Yuriy Semchyshyn commented on CASSANDRASC-102: -- This is a follow-up issue to https://issues.apache.org/jira/browse/CASSANDRASC-86 that has already been committed. The reviewed patch is here: https://github.com/apache/cassandra-analytics/pull/22. The successful build is here: https://app.circleci.com/pipelines/github/5/cassandra-analytics/49/workflows/8ac5b581-e015-4c7f-b1ed-1b5bd9f4976c. > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Semchyshyn updated CASSANDRASC-102: - Authors: Yuriy Semchyshyn Test and Documentation Plan: https://app.circleci.com/pipelines/github/5/cassandra-analytics/49/workflows/8ac5b581-e015-4c7f-b1ed-1b5bd9f4976c Status: Patch Available (was: Open) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
[ https://issues.apache.org/jira/browse/CASSANDRASC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Semchyshyn updated CASSANDRASC-102: - Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Startup Validation Failures when Checking Sidecar Connectivity (Analytics) > -- > > Key: CASSANDRASC-102 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yuriy Semchyshyn >Priority: Normal > > We have experienced repeated startup validation failures caused by Sidecar > health checks for some jobs with a large number of Spark executors. > It is worth increasing the overall timeout for Sidecar health checks from > current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-102) Startup Validation Failures when Checking Sidecar Connectivity (Analytics)
Yuriy Semchyshyn created CASSANDRASC-102: Summary: Startup Validation Failures when Checking Sidecar Connectivity (Analytics) Key: CASSANDRASC-102 URL: https://issues.apache.org/jira/browse/CASSANDRASC-102 Project: Sidecar for Apache Cassandra Issue Type: Improvement Components: Configuration Reporter: Yuriy Semchyshyn We have experienced repeated startup validation failures caused by Sidecar health checks for some jobs with a large number of Spark executors. It is worth increasing the overall timeout for Sidecar health checks from current 30 seconds to 5 minutes and making it configurable. -- 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] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-101: - Summary: Upgrade Vert.x version in Sidecar to 4.5 (was: Upgrade Vert.x version in Sidecar to 4.5.3) > Upgrade Vert.x version in Sidecar to 4.5 > > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5.3 Vert.x version. -- 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] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-101: - Description: There was a memory leak identified in 4.4 branch in Vert.x [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x version, hence we need to upgrade to 4.5 Vert.x version. (was: There was a memory leak identified in 4.4 branch in Vert.x [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x version, hence we need to upgrade to 4.5.3 Vert.x version. ) > Upgrade Vert.x version in Sidecar to 4.5 > > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5 Vert.x version. -- 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] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5.3
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-101: - Summary: Upgrade Vert.x version in Sidecar to 4.5.3 (was: Upgrade Vert.x version in Sidecar to 4.5.2) > Upgrade Vert.x version in Sidecar to 4.5.3 > -- > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5.2 Vert.x version. -- 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] (CASSANDRASC-101) Upgrade Vert.x version in Sidecar to 4.5.3
[ https://issues.apache.org/jira/browse/CASSANDRASC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-101: - Description: There was a memory leak identified in 4.4 branch in Vert.x [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x version, hence we need to upgrade to 4.5.3 Vert.x version. (was: There was a memory leak identified in 4.4 branch in Vert.x [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x version, hence we need to upgrade to 4.5.2 Vert.x version. ) > Upgrade Vert.x version in Sidecar to 4.5.3 > -- > > Key: CASSANDRASC-101 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-101 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: High > > There was a memory leak identified in 4.4 branch in Vert.x > [https://github.com/eclipse-vertx/vert.x/pull/5082]. This was fixed in 4.5 > branch, and a release was out 10 days ago. Sidecar is on 4.4.6 Vert.x > version, hence we need to upgrade to 4.5.3 Vert.x version. -- 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-19018) An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815394#comment-17815394
]
Caleb Rackliffe commented on CASSANDRA-19018:
-
[~adelapena] Read repair is enabled again
[here|https://github.com/maedhroz/cassandra/pull/15/commits]. I was incorrectly
sending an empty static row to the coordinator when resolution was required.
Now I think all that remains is short-read protection for post-RFP filtering...
> An SAI-specific mechanism to ensure consistency isn't violated for
> multi-column (i.e. AND) queries at CL > ONE
> --
>
> Key: CASSANDRA-19018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19018
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> result_details.tar-1.gz, result_details.tar.gz
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-19007 is going to be where we add a guardrail around
> filtering/index queries that use intersection/AND over partially updated
> non-key columns. (ex. Restricting one clustering column and one normal column
> does not cause a consistency problem, as primary keys cannot be partially
> updated.) This issue exists to attempt to fix this specifically for SAI in
> 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.
> The SAI-specific version of the originally reported issue is this:
> {noformat}
> try (Cluster cluster = init(Cluster.build(2).withConfig(config ->
> config.with(GOSSIP).with(NETWORK)).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int
> PRIMARY KEY, a int, b int)"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING
> 'sai'"));
> cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING
> 'sai'"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> a) VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k,
> b) VALUES (0, 2)"));
> // Uncomment this line and test succeeds w/ partial writes
> completed...
> //cluster.get(1).nodetoolResult("repair",
> KEYSPACE).asserts().success();
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND
> b = 2");
> Object[][] initialRows = cluster.coordinator(1).execute(select,
> ConsistencyLevel.ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> {noformat}
> To make a long story short, the local SAI indexes are hiding local partial
> matches from the coordinator that would combine there to form full matches.
> Simple non-index filtering queries also suffer from this problem, but they
> hide the partial matches in a different way. I'll outline a possible solution
> for this in the comments that takes advantage of replica filtering protection
> and the repaired/unrepaired datasets...and attempts to minimize the amount of
> extra row data sent to the coordinator.
--
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
(cassandra) branch cep-15-accord updated (a7c63e05d5 -> 90b7049823)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git discard a7c63e05d5 Fix simulator logging add 90b7049823 Fix simulator logging and clean shutdown 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 (a7c63e05d5) \ N -- N -- N refs/heads/cep-15-accord (90b7049823) 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: src/java/org/apache/cassandra/gms/Gossiper.java | 5 + src/java/org/apache/cassandra/index/IndexStatusManager.java | 8 src/java/org/apache/cassandra/service/accord/AccordJournal.java | 5 - .../org/apache/cassandra/distributed/impl/Instance.java | 9 - .../asm/org/apache/cassandra/simulator/asm/InterceptAgent.java | 2 -- .../asm/org/apache/cassandra/simulator/asm/StringHashcode.java | 1 - .../main/org/apache/cassandra/simulator/ClusterSimulation.java | 4 .../main/org/apache/cassandra/simulator/SimulationRunner.java| 1 - 8 files changed, 25 insertions(+), 10 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cep-15-accord updated (98c0b004ac -> a7c63e05d5)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git from 98c0b004ac Get simulator working (again) add f7de0c40a0 Fix (de)serialization of WaitingOn into cache add a7c63e05d5 Fix simulator logging No new revisions were added by this update. Summary of changes: .../apache/cassandra/service/accord/AccordKeyspace.java | 4 +--- .../service/accord/serializers/WaitingOnSerializer.java | 16 +++- test/conf/logback-simulator.xml | 5 +++-- .../apache/cassandra/simulator/ClusterSimulation.java| 11 +-- .../org/apache/cassandra/simulator/SimulationRunner.java | 11 ++- .../cassandra/simulator/logging/RunStartDefiner.java | 6 ++ 6 files changed, 36 insertions(+), 17 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19333: Reviewers: Bret McGuire, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
[
https://issues.apache.org/jira/browse/CASSANDRA-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17298:
Fix Version/s: (was: 4.1.x)
> Test Failure:
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
> ---
>
> Key: CASSANDRA-17298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
> Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
> Error Message
> Expected heap usage close to 49.930MiB, got 41.542MiB.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
> got 41.542MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
> at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
> at org.apache.cassandra.Util.flakyTest(Util.java:669)
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
> 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)
> {code}
--
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-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
[
https://issues.apache.org/jira/browse/CASSANDRA-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17298:
Fix Version/s: 4.1.x
> Test Failure:
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
> ---
>
> Key: CASSANDRA-17298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
> Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
> Error Message
> Expected heap usage close to 49.930MiB, got 41.542MiB.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
> got 41.542MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
> at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
> at org.apache.cassandra.Util.flakyTest(Util.java:669)
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
> 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)
> {code}
--
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-19373) 5.0 updates FQL format, but doesn't update version or handle reading old version files
[ https://issues.apache.org/jira/browse/CASSANDRA-19373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19373: --- Resolution: Not A Bug Status: Resolved (was: Open) Turns out Chronicle wire encodes the width of the int and can read it back safely as a wider type. > 5.0 updates FQL format, but doesn't update version or handle reading old > version files > -- > > Key: CASSANDRA-19373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19373 > Project: Cassandra > Issue Type: Bug > Components: Tool/fql >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 5.0-rc, 5.x > > -- 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
(cassandra-website) branch asf-staging updated (8864655f -> ebd3b488)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 8864655f generate docs for a1ebc6a8 new ebd3b488 generate docs for a1ebc6a8 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 (8864655f) \ N -- N -- N refs/heads/asf-staging (ebd3b488) 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. 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: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19373) 5.0 updates FQL format, but doesn't update version or handle reading old version files
[ https://issues.apache.org/jira/browse/CASSANDRA-19373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815340#comment-17815340 ] Stefan Miklosovic commented on CASSANDRA-19373: --- I can not reproduce it. I just generated some fql / chronicle data by org.apache.cassandra.fqltool.FQLReplayTest.generateQueries on cassandra-4.1 branch. Then I took what it produced and I dumped it by org.apache.cassandra.fqltool.commands.Dump.dump(). > 5.0 updates FQL format, but doesn't update version or handle reading old > version files > -- > > Key: CASSANDRA-19373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19373 > Project: Cassandra > Issue Type: Bug > Components: Tool/fql >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 5.0-rc, 5.x > > -- 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
(cassandra) branch cep-15-accord updated (6f59f68c1b -> 98c0b004ac)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git discard 6f59f68c1b Get simulator working (again) add 98c0b004ac Get simulator working (again) 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 (6f59f68c1b) \ N -- N -- N refs/heads/cep-15-accord (98c0b004ac) 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: src/java/org/apache/cassandra/utils/concurrent/Semaphore.java| 1 - .../test/org/apache/cassandra/simulator/test/SimulationTestBase.java | 1 - 2 files changed, 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Get simulator working (again)
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 6f59f68c1bab37ed1c77794d7382bfdc09c405f3
Author: David Capwell
AuthorDate: Wed Oct 4 15:13:37 2023 -0700
Get simulator working (again)
Co-authored-by: Ariel Weisberg
Co-authored-by: Benedict Elliott Smith
---
.build/checkstyle_suppressions.xml | 1 -
build.xml | 18
.../cassandra/concurrent/InfiniteLoopExecutor.java | 5 +
.../config/CassandraRelevantProperties.java| 1 +
.../db/memtable/AbstractAllocatorMemtable.java | 6 ++
.../apache/cassandra/journal/ActiveSegment.java| 9 ++
src/java/org/apache/cassandra/journal/Flusher.java | 29 --
src/java/org/apache/cassandra/journal/Journal.java | 3 +
src/java/org/apache/cassandra/journal/Params.java | 2 +-
.../cassandra/metrics/AccordStateCacheMetrics.java | 6 +-
.../service/accord/AccordConfigurationService.java | 61 +---
.../service/accord/AccordFastPathCoordinator.java | 2 +-
.../cassandra/service/accord/AccordJournal.java| 4 +-
.../cassandra/service/accord/AccordService.java| 33 +--
.../cassandra/utils/concurrent/Semaphore.java | 4 +-
.../cassandra/distributed/impl/Instance.java | 3 +
.../distributed/impl/IsolatedExecutor.java | 2 +-
.../cassandra/simulator/asm/ClassTransformer.java | 4 +
.../simulator/asm/GlobalMethodTransformer.java | 3 +-
.../cassandra/simulator/asm/InterceptAgent.java| 106 -
.../cassandra/simulator/asm/InterceptClasses.java | 2 +
.../simulator/asm/MonitorMethodTransformer.java| 3 +-
.../cassandra/simulator/asm/StringHashcode.java| 44 +
.../apache/cassandra/simulator/ActionSchedule.java | 17 ++--
.../cassandra/simulator/ClusterSimulation.java | 5 +
.../cassandra/simulator/SimulationRunner.java | 12 +++
.../simulator/cluster/KeyspaceActions.java | 1 +
.../apache/cassandra/simulator/debug/Record.java | 4 +-
.../cassandra/simulator/debug/SelfReconcile.java | 2 +
.../AbstractPairOfSequencesPaxosSimulation.java| 11 +--
.../simulator/paxos/AccordClusterSimulation.java | 5 +-
.../simulator/paxos/AccordSimulationRunner.java| 27 ++
.../paxos/PairOfSequencesAccordSimulation.java | 6 +-
.../simulator/paxos/PaxosSimulationRunner.java | 2 +
.../simulator/systems/InterceptingMonitors.java| 3 -
.../simulator/test/SimulationTestBase.java | 1 +
.../org/apache/cassandra/journal/TestParams.java | 2 +-
37 files changed, 386 insertions(+), 63 deletions(-)
diff --git a/.build/checkstyle_suppressions.xml
b/.build/checkstyle_suppressions.xml
index ed4d1443f7..230c808c14 100644
--- a/.build/checkstyle_suppressions.xml
+++ b/.build/checkstyle_suppressions.xml
@@ -21,5 +21,4 @@
"https://checkstyle.org/dtds/suppressions_1_1.dtd;>
-
diff --git a/build.xml b/build.xml
index 53b273478f..e0bbe27b17 100644
--- a/build.xml
+++ b/build.xml
@@ -223,6 +223,24 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/java/org/apache/cassandra/concurrent/InfiniteLoopExecutor.java
b/src/java/org/apache/cassandra/concurrent/InfiniteLoopExecutor.java
index 51c5f9f69e..97410a9138 100644
--- a/src/java/org/apache/cassandra/concurrent/InfiniteLoopExecutor.java
+++ b/src/java/org/apache/cassandra/concurrent/InfiniteLoopExecutor.java
@@ -52,6 +52,11 @@ public class InfiniteLoopExecutor implements Interruptible
@Shared(scope = Shared.Scope.SIMULATION)
public enum SimulatorSafe { SAFE, UNSAFE }
+/**
+ * Does this loop always block on some external work provision that is
going to be simulator-controlled, or does
+ * it loop periodically? If the latter, it may prevent simulation making
progress between phases, and should be
+ * marked as a DAEMON process.
+ */
@Shared(scope = Shared.Scope.SIMULATION)
public enum Daemon{ DAEMON, NON_DAEMON }
diff --git
a/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
index 3cbfab0307..c6cfe9e3db 100644
--- a/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
+++ b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
@@ -564,6 +564,7 @@ public enum CassandraRelevantProperties
* faster. Note that this is disabled for unit tests but if an individual
test requires schema to be flushed, it
* can be also done manually for that particular case: {@code
flush(SchemaConstants.SCHEMA_KEYSPACE_NAME);}. */
TEST_FLUSH_LOCAL_SCHEMA_CHANGES("cassandra.test.flush_local_schema_changes",
"true"),
+
(cassandra) branch cep-15-accord updated (a6c58187b0 -> 6f59f68c1b)
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a change to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
omit a6c58187b0 Get simulator working (again)
new 6f59f68c1b Get simulator working (again)
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 (a6c58187b0)
\
N -- N -- N refs/heads/cep-15-accord (6f59f68c1b)
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.
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:
rio/run-simulator.sh | 51 --
.../cassandra/metrics/AccordStateCacheMetrics.java | 6 ++-
.../cassandra/distributed/impl/Instance.java | 3 ++
.../distributed/impl/IsolatedExecutor.java | 2 +-
.../cassandra/simulator/asm/InterceptAgent.java| 30 -
.../asm/{Hashcode.java => StringHashcode.java} | 8 ++--
.../cassandra/simulator/ClusterSimulation.java | 1 +
.../cassandra/simulator/SimulationRunner.java | 12 +
.../apache/cassandra/simulator/debug/Record.java | 4 +-
.../cassandra/simulator/debug/SelfReconcile.java | 2 +
.../simulator/paxos/AccordClusterSimulation.java | 5 ++-
.../simulator/paxos/AccordSimulationRunner.java| 16 +++
.../simulator/paxos/PaxosSimulationRunner.java | 2 +
.../simulator/systems/InterceptingMonitors.java| 3 --
14 files changed, 81 insertions(+), 64 deletions(-)
delete mode 100755 rio/run-simulator.sh
copy test/simulator/asm/org/apache/cassandra/simulator/asm/{Hashcode.java =>
StringHashcode.java} (81%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17062) Refactor structure of caching metrics to weighted and unweighted
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815326#comment-17815326 ] Maxim Muzafarov commented on CASSANDRA-17062: - I've reviewed the changes [1], +1 LGMT [1] https://github.com/apache/cassandra/pull/3002 > Refactor structure of caching metrics to weighted and unweighted > - > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18824: -- Fix Version/s: 3.0.30 3.11.17 4.0.12 4.1.4 5.0-rc 5.1 (was: 3.0.x) (was: 3.11.x) (was: 5.x) (was: 4.0.x) (was: 4.1.x) (was: 5.0.x) Source Control Link: https://github.com/apache/cassandra/commit/5be57829b03ef980933ba52ecc0549787f653da4 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.30, 3.11.17, 4.0.12, 4.1.4, 5.0-rc, 5.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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
(cassandra) branch cassandra-4.0 updated (1e450dbb1a -> 9613af24f3)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1e450dbb1a Merge branch 'cassandra-3.11' into cassandra-4.0 add 5be57829b0 Backport CASSANDRA-16418 to 3.x add 2170825f0e Merge branch 'cassandra-3.0' into cassandra-3.11 add 9613af24f3 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 6 ++- .../apache/cassandra/locator/SimpleStrategy.java | 2 +- .../apache/cassandra/service/StorageService.java | 2 +- .../distributed/test/ring/CleanupFailureTest.java | 48 +- test/unit/org/apache/cassandra/db/CleanupTest.java | 45 6 files changed, 81 insertions(+), 23 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-5.0 updated (1086d10965 -> 78dca99973)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1086d10965 In-jvm dtest RepairTest fails with storage_compatibility_mode: NONE add 5be57829b0 Backport CASSANDRA-16418 to 3.x add 2170825f0e Merge branch 'cassandra-3.0' into cassandra-3.11 add 9613af24f3 Merge branch 'cassandra-3.11' into cassandra-4.0 add d9dbd5e1d0 Merge branch 'cassandra-4.0' into cassandra-4.1 add 78dca99973 Merge branch 'cassandra-4.1' into cassandra-5.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 6 ++- .../apache/cassandra/locator/SimpleStrategy.java | 2 +- .../apache/cassandra/service/StorageService.java | 2 +- .../distributed/test/ring/CleanupFailureTest.java | 48 +++- test/unit/org/apache/cassandra/db/CleanupTest.java | 52 -- 6 files changed, 84 insertions(+), 27 deletions(-) - 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-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository.
jlewandowski pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 097c1231e2466163fe3f8b36b12cdc5235eb1403
Merge: 1a971dab7e 78dca99973
Author: Jacek Lewandowski
AuthorDate: Wed Feb 7 15:12:04 2024 +0100
Merge branch 'cassandra-5.0' into trunk
* cassandra-5.0:
Backport CASSANDRA-16418 to 3.x
CHANGES.txt| 1 +
.../test/ring/CleanupDuringRangeMovementTest.java | 56 --
2 files changed, 32 insertions(+), 25 deletions(-)
diff --cc CHANGES.txt
index a6107c29a8,1549165f6c..367d65ecdb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -28,11 -15,15 +28,12 @@@ Merged from 5.0
* Fix resource cleanup after SAI query timeouts (CASSANDRA-19177)
* Suppress CVE-2023-6481 (CASSANDRA-19184)
Merged from 4.1:
- * Memoize Cassandra verion and add a backoff interval for failed schema
pulls (CASSANDRA-18902)
* Fix StackOverflowError on ALTER after many previous schema changes
(CASSANDRA-19166)
+ * Memoize Cassandra verion (CASSANDRA-18902)
Merged from 4.0:
- * Skip version check if an endpoint is dead state in
Gossiper#upgradeFromVersionSupplier (CASSANDRA-19187)
- * Fix Gossiper::hasMajorVersion3Nodes to return false during minor upgrade
(CASSANDRA-18999)
- * Revert unnecessary read lock acquisition when reading ring version in
TokenMetadata introduced in CASSANDRA-16286 (CASSANDRA-19107)
Merged from 3.11:
Merged from 3.0:
+ * Backport CASSANDRA-16418 to 3.x (CASSANDRA-18824)
5.0-beta1
diff --cc
test/distributed/org/apache/cassandra/distributed/test/ring/CleanupDuringRangeMovementTest.java
index bc46a1fe7b,00..8e80732400
mode 100644,00..100644
---
a/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupDuringRangeMovementTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupDuringRangeMovementTest.java
@@@ -1,145 -1,0 +1,151 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed.test.ring;
+
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.junit.Test;
+
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.Constants;
+import org.apache.cassandra.distributed.api.ConsistencyLevel;
+import org.apache.cassandra.distributed.api.IInstanceConfig;
+import org.apache.cassandra.distributed.api.IInvokableInstance;
+import org.apache.cassandra.distributed.api.NodeToolResult;
+import org.apache.cassandra.distributed.shared.NetworkTopology;
+import org.apache.cassandra.distributed.test.TestBaseImpl;
+import org.apache.cassandra.tcm.transformations.PrepareJoin;
+import org.apache.cassandra.tcm.transformations.PrepareLeave;
+
++import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
++import static org.apache.cassandra.distributed.api.Feature.NETWORK;
++import static
org.apache.cassandra.distributed.api.TokenSupplier.evenlyDistributedTokens;
+import static
org.apache.cassandra.distributed.shared.ClusterUtils.decommission;
+import static
org.apache.cassandra.distributed.shared.ClusterUtils.pauseBeforeCommit;
+import static
org.apache.cassandra.distributed.shared.ClusterUtils.unpauseCommits;
- import static
org.apache.cassandra.distributed.test.ring.BootstrapTest.populateExistingTable;
+import static org.junit.Assert.assertEquals;
- import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
- import static org.apache.cassandra.distributed.api.Feature.NETWORK;
- import static
org.apache.cassandra.distributed.api.TokenSupplier.evenlyDistributedTokens;
+import static org.junit.Assert.assertTrue;
+
+public class CleanupDuringRangeMovementTest extends TestBaseImpl
+{
+@Test
+public void cleanupDuringDecommissionTest() throws Throwable
+{
+ExecutorService executor = Executors.newSingleThreadExecutor();
- try (Cluster cluster = builder().withNodes(2)
-
(cassandra) branch trunk updated (1a971dab7e -> 097c1231e2)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1a971dab7e Merge branch 'cassandra-5.0' into trunk add 5be57829b0 Backport CASSANDRA-16418 to 3.x add 2170825f0e Merge branch 'cassandra-3.0' into cassandra-3.11 add 9613af24f3 Merge branch 'cassandra-3.11' into cassandra-4.0 add d9dbd5e1d0 Merge branch 'cassandra-4.0' into cassandra-4.1 add 78dca99973 Merge branch 'cassandra-4.1' into cassandra-5.0 new 097c1231e2 Merge branch 'cassandra-5.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: CHANGES.txt| 1 + .../test/ring/CleanupDuringRangeMovementTest.java | 56 -- 2 files changed, 32 insertions(+), 25 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 (653337ed06 -> 2170825f0e)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 653337ed06 Merge branch 'cassandra-3.0' into cassandra-3.11 add 5be57829b0 Backport CASSANDRA-16418 to 3.x add 2170825f0e Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 4 +- .../apache/cassandra/service/StorageService.java | 3 + .../cassandra/distributed/action/GossipHelper.java | 16 +++ .../distributed/test/CleanupFailureTest.java | 118 + test/unit/org/apache/cassandra/db/CleanupTest.java | 48 - 6 files changed, 186 insertions(+), 4 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/CleanupFailureTest.java - 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 (0bc95bbebd -> 5be57829b0)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0bc95bbebd Set log-cli-level to DEBUG in circle config add 5be57829b0 Backport CASSANDRA-16418 to 3.x No new revisions were added by this update. Summary of changes: CHANGES.txt| 18 ++-- .../cassandra/db/compaction/CompactionManager.java | 4 +- .../apache/cassandra/service/StorageService.java | 3 + .../cassandra/distributed/action/GossipHelper.java | 16 +++ .../distributed/test/CleanupFailureTest.java | 118 + test/unit/org/apache/cassandra/db/CleanupTest.java | 48 - 6 files changed, 197 insertions(+), 10 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/CleanupFailureTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.1 updated (cd7ff04e72 -> d9dbd5e1d0)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from cd7ff04e72 Merge branch 'cassandra-4.0' into cassandra-4.1 add 5be57829b0 Backport CASSANDRA-16418 to 3.x add 2170825f0e Merge branch 'cassandra-3.0' into cassandra-3.11 add 9613af24f3 Merge branch 'cassandra-3.11' into cassandra-4.0 add d9dbd5e1d0 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 6 ++- .../apache/cassandra/locator/SimpleStrategy.java | 2 +- .../apache/cassandra/service/StorageService.java | 2 +- .../distributed/test/ring/CleanupFailureTest.java | 48 +++- test/unit/org/apache/cassandra/db/CleanupTest.java | 52 -- 6 files changed, 84 insertions(+), 27 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815299#comment-17815299 ] Stefan Miklosovic commented on CASSANDRA-16999: --- This will probably not make it to anything but trunk where we add that column to system_views.peers. That being said when we do not deprecate the dual port support altogether. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815295#comment-17815295 ] Brandon Williams commented on CASSANDRA-16999: -- After the [ML discussion|https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv], [~steve.lace...@datastax.com] is this really needed after CASSANDRA-10559? > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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
(cassandra) branch cep-15-accord updated (81594f4f0b -> a6c58187b0)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git discard 81594f4f0b Get simulator working (again) add a6c58187b0 Get simulator working (again) 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 (81594f4f0b) \ N -- N -- N refs/heads/cep-15-accord (a6c58187b0) 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: src/java/org/apache/cassandra/config/CassandraRelevantProperties.java | 3 +-- .../cassandra/simulator/paxos/PairOfSequencesAccordSimulation.java | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815272#comment-17815272 ] Brandon Williams commented on CASSANDRA-19375: -- [~polandll] can you take a look? I think we can just remove this now, the last I recall of a working Achilles site told people it's not maintained and to not use it, which seems accurate. > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: PJ Fanning >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- 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
(cassandra) branch cep-15-accord updated (531d9e1afd -> 81594f4f0b)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git from 531d9e1afd Fix SerializerSupport.reconstruct, and introduce RangeFactory add 81594f4f0b Get simulator working (again) No new revisions were added by this update. Summary of changes: .build/checkstyle_suppressions.xml | 1 - build.xml | 18 + rio/run-simulator.sh | 51 +++ .../cassandra/concurrent/InfiniteLoopExecutor.java | 5 ++ .../config/CassandraRelevantProperties.java| 2 + .../db/memtable/AbstractAllocatorMemtable.java | 6 ++ .../apache/cassandra/journal/ActiveSegment.java| 9 +++ src/java/org/apache/cassandra/journal/Flusher.java | 29 +++-- src/java/org/apache/cassandra/journal/Journal.java | 3 + src/java/org/apache/cassandra/journal/Params.java | 2 +- .../service/accord/AccordConfigurationService.java | 61 + .../service/accord/AccordFastPathCoordinator.java | 2 +- .../cassandra/service/accord/AccordJournal.java| 4 +- .../cassandra/service/accord/AccordService.java| 33 -- .../cassandra/utils/concurrent/Semaphore.java | 4 +- .../cassandra/simulator/asm/ClassTransformer.java | 4 ++ .../simulator/asm/GlobalMethodTransformer.java | 3 +- .../cassandra/simulator/asm/InterceptAgent.java| 76 -- .../cassandra/simulator/asm/InterceptClasses.java | 2 + .../simulator/asm/MonitorMethodTransformer.java| 3 +- .../apache/cassandra/simulator/ActionSchedule.java | 17 +++-- .../cassandra/simulator/ClusterSimulation.java | 4 ++ .../simulator/cluster/KeyspaceActions.java | 1 + .../AbstractPairOfSequencesPaxosSimulation.java| 11 +--- .../simulator/paxos/AccordSimulationRunner.java| 11 .../paxos/PairOfSequencesAccordSimulation.java | 6 +- .../simulator/test/SimulationTestBase.java | 1 + .../org/apache/cassandra/journal/TestParams.java | 2 +- 28 files changed, 317 insertions(+), 54 deletions(-) create mode 100755 rio/run-simulator.sh - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19375: - Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: PJ Fanning >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- 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-19261) Test failure: org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815267#comment-17815267
]
Andres de la Peña commented on CASSANDRA-19261:
---
I've just seen it on a patch for 4.1:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/3424/workflows/7e153df1-c7c3-453d-9003-e1cacaf0d9fb/jobs/103446/tests]
{code:java}
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: Feature.JMX was enabled but could not be started.
at org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:73)
at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:514)
at
org.apache.cassandra.distributed.impl.AbstractCluster.parallelForEach(AbstractCluster.java:787)
at
org.apache.cassandra.distributed.impl.AbstractCluster.startup(AbstractCluster.java:1050)
at
org.apache.cassandra.distributed.shared.AbstractBuilder.start(AbstractBuilder.java:166)
at
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest.testJmxFeatures(JMXFeatureTest.java:78)
at
org.apache.cassandra.distributed.test.jmx.JMXFeatureTest.testOneNetworkInterfaceProvisioning(JMXFeatureTest.java:66)
Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException:
Feature.JMX was enabled but could not be started.
at
org.apache.cassandra.utils.concurrent.AbstractFuture.getWhenDone(AbstractFuture.java:239)
at
org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:246)
at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:501)
Caused by: java.lang.RuntimeException: Feature.JMX was enabled but could not be
started.
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:136)
at
org.apache.cassandra.distributed.impl.Instance.startJmx(Instance.java:770)
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$12(Instance.java:616)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:750)
Caused by: java.rmi.server.ExportException: Port already in use: 34863; nested
exception is:
java.net.BindException: Address already in use (Bind failed)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:254)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:237)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:213)
at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:173)
at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:144)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:339)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
Caused by: java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:390)
at java.net.ServerSocket.(ServerSocket.java:252)
at
javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:50)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
{code}
> Test failure: org.apache.cassandra.distributed.test.jmx.JMXFeatureTest
> --
>
> Key: CASSANDRA-19261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19261
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Two of the tests in the class are flaky as seen here:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=pre-18688-JMXFeatureTest
> This is from trunk, but I
[jira] [Comment Edited] (CASSANDRA-19336) Repair causes out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-19336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815259#comment-17815259
]
Andres de la Peña edited comment on CASSANDRA-19336 at 2/7/24 11:59 AM:
The CI results above look good to me:
* {{MemtableSizeTest.testTruncationReleasesLogSpace}} in 4.0 is
CASSANDRA-17298.
* {{RepairJobTest.testNoTreesRetainedAfterDifference}} in 4.0 is
CASSANDRA-17884.
* {{JMXFeatureTest.testOneNetworkInterfaceProvisioning}} in 4.1 is
CASSANDRA-19261.
* {{MemtableSizeTest.testSize[skiplist]}} in 4.1 is CASSANDRA-17298.
* {{VectorUpdateDeleteTest.updateTest}} in 5.0 and trunk is CASSANDRA-19168.
* {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}} in trunk
is unreported, but it can be [reproduced on the base
branch|https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598/jobs/103861/tests].
I've created CASSANDRA-19376 for it.
* {{HarrySimulatorTest}} in trunk is CASSANDRA-19279.
* {{InJVMTokenAwareExecutorTest.testRepair}} in trunk is a timeout seen on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
*
{{ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload}}
in trunk is on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk].
*
{{NativeTransportEncryptionOptionsTest.optionalTlsConnectionAllowedToRegularPortTest}}
in trunk is CASSANDRA-19239.
*
{{NativeTransportEncryptionOptionsTest.testOptionalMtlsModeDoNotAllowNonSSLConnections}}
in trunk is CASSANDRA-19239.
* {{ConsistentBootstrapTest.coordinatorIsBehindTest}} in trunk is
CASSANDRA-19343.
was (Author: adelapena):
The CI results above look good to me:
* {{MemtableSizeTest.testTruncationReleasesLogSpace}} in 4.0 is CASSANDRA-17298
* {{RepairJobTest.testNoTreesRetainedAfterDifference}} in 4.0 is CASSANDRA-17884
* {{JMXFeatureTest.testOneNetworkInterfaceProvisioning}} in 4.1 is
CASSANDRA-19261
* {{MemtableSizeTest.testSize[skiplist]}} in 4.1 is CASSANDRA-17298
* {{VectorUpdateDeleteTest.updateTest}} in 5.0 and trunk is CASSANDRA-19168
* {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}} in trunk is
unreported, but it can be [reproduced on the base
branch|https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598/jobs/103861/tests].
* {{HarrySimulatorTest}} in trunk is CASSANDRA-19279
* {{InJVMTokenAwareExecutorTest.testRepair}} in trunk is a timeout seen on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
* {{ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload}}
in trunk is on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
*
{{NativeTransportEncryptionOptionsTest.optionalTlsConnectionAllowedToRegularPortTest}}
in trunk is CASSANDRA-19239
*
{{NativeTransportEncryptionOptionsTest.testOptionalMtlsModeDoNotAllowNonSSLConnections}}
in trunk is CASSANDRA-19239
* {{ConsistentBootstrapTest.coordinatorIsBehindTest}} in trunk is
CASSANDRA-19343.
> Repair causes out of memory
> ---
>
> Key: CASSANDRA-19336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19336
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CASSANDRA-14096 introduced {{repair_session_space}} as a limit for the memory
> usage for Merkle tree calculations during repairs. This limit is applied to
> the set of Merkle trees built for a received validation request
> ({{{}VALIDATION_REQ{}}}), divided by the replication factor so as not to
> overwhelm the repair coordinator, who will have requested RF sets of Merkle
> trees. That way the repair coordinator should only use
> {{repair_session_space}} for the RF Merkle trees.
> However, a repair session without {{{}-pr-{}}}/{{{}-partitioner-range{}}}
> will send RF*RF validation requests, because the repair coordinator node has
> RF-1 replicas and is also the replica of RF-1 nodes. Since all the requests
> are sent at the same time, at some point the repair coordinator can have up
> to RF*{{{}repair_session_space{}}} worth of Merkle trees if none of the
> validation responses is fully processed before the last response arrives.
> Even worse, if the cluster uses virtual nodes, many nodes can be replicas of
> the repair coordinator, and some nodes can be replicas of multiple token
> ranges. It would mean that the repair coordinator can send more than RF or
> RF*RF simultaneous validation requests.
> For
[jira] [Updated] (CASSANDRA-19376) CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-19376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19376:
--
Fix Version/s: 5.x
> CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
> --
>
> Key: CASSANDRA-19376
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19376
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The unit test
> {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}} fails
> occasionally at least in {{trunk}}:
> {code}
> unit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency(CompactionStrategyManagerTest.java:227)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598
> The failure can be reproduced with:
> {code}
> .circleci/generate.sh -p \
> -e
> REPEATED_UTESTS=org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
> \
> -e REPEATED_UTESTS_COUNT=1000
> {code}
> I have only tested trunk. I haven't seen it on Butler.
> Observed flakiness is ~0.2% for all jobs except for tries, which ramps up to
> ~2.5%.
--
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-19376) CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
Andres de la Peña created CASSANDRA-19376:
-
Summary:
CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
Key: CASSANDRA-19376
URL: https://issues.apache.org/jira/browse/CASSANDRA-19376
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Andres de la Peña
The unit test {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}}
fails occasionally at least in {{trunk}}:
{code}
unit.framework.AssertionFailedError: expected:<1> but was:<0>
at
org.apache.cassandra.db.compaction.CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency(CompactionStrategyManagerTest.java:227)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598
The failure can be reproduced with:
{code}
.circleci/generate.sh -p \
-e
REPEATED_UTESTS=org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
\
-e REPEATED_UTESTS_COUNT=1000
{code}
I have only tested trunk. I haven't seen it on Butler.
Observed flakiness is ~0.2% for all jobs except for tries, which ramps up to
~2.5%.
--
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-19376) CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-19376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-19376:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency is flaky
> --
>
> Key: CASSANDRA-19376
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19376
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
>
> The unit test
> {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}} fails
> occasionally at least in {{trunk}}:
> {code}
> unit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency(CompactionStrategyManagerTest.java:227)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598
> The failure can be reproduced with:
> {code}
> .circleci/generate.sh -p \
> -e
> REPEATED_UTESTS=org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
> \
> -e REPEATED_UTESTS_COUNT=1000
> {code}
> I have only tested trunk. I haven't seen it on Butler.
> Observed flakiness is ~0.2% for all jobs except for tries, which ramps up to
> ~2.5%.
--
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-19336) Repair causes out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-19336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815259#comment-17815259
]
Andres de la Peña commented on CASSANDRA-19336:
---
The CI results above look good to me:
* {{MemtableSizeTest.testTruncationReleasesLogSpace}} in 4.0 is CASSANDRA-17298
* {{RepairJobTest.testNoTreesRetainedAfterDifference}} in 4.0 is CASSANDRA-17884
* {{JMXFeatureTest.testOneNetworkInterfaceProvisioning}} in 4.1 is
CASSANDRA-19261
* {{MemtableSizeTest.testSize[skiplist]}} in 4.1 is CASSANDRA-17298
* {{VectorUpdateDeleteTest.updateTest}} in 5.0 and trunk is CASSANDRA-19168
* {{CompactionStrategyManagerTest.testAutomaticUpgradeConcurrency}} in trunk is
unreported, but it can be [reproduced on the base
branch|https://app.circleci.com/pipelines/github/adelapena/cassandra/3427/workflows/126307ce-d465-4736-a71e-82e0b8749598/jobs/103861/tests].
* {{HarrySimulatorTest}} in trunk is CASSANDRA-19279
* {{InJVMTokenAwareExecutorTest.testRepair}} in trunk is a timeout seen on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
* {{ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload}}
in trunk is on
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
*
{{NativeTransportEncryptionOptionsTest.optionalTlsConnectionAllowedToRegularPortTest}}
in trunk is CASSANDRA-19239
*
{{NativeTransportEncryptionOptionsTest.testOptionalMtlsModeDoNotAllowNonSSLConnections}}
in trunk is CASSANDRA-19239
* {{ConsistentBootstrapTest.coordinatorIsBehindTest}} in trunk is
CASSANDRA-19343.
> Repair causes out of memory
> ---
>
> Key: CASSANDRA-19336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19336
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CASSANDRA-14096 introduced {{repair_session_space}} as a limit for the memory
> usage for Merkle tree calculations during repairs. This limit is applied to
> the set of Merkle trees built for a received validation request
> ({{{}VALIDATION_REQ{}}}), divided by the replication factor so as not to
> overwhelm the repair coordinator, who will have requested RF sets of Merkle
> trees. That way the repair coordinator should only use
> {{repair_session_space}} for the RF Merkle trees.
> However, a repair session without {{{}-pr-{}}}/{{{}-partitioner-range{}}}
> will send RF*RF validation requests, because the repair coordinator node has
> RF-1 replicas and is also the replica of RF-1 nodes. Since all the requests
> are sent at the same time, at some point the repair coordinator can have up
> to RF*{{{}repair_session_space{}}} worth of Merkle trees if none of the
> validation responses is fully processed before the last response arrives.
> Even worse, if the cluster uses virtual nodes, many nodes can be replicas of
> the repair coordinator, and some nodes can be replicas of multiple token
> ranges. It would mean that the repair coordinator can send more than RF or
> RF*RF simultaneous validation requests.
> For example, in an 11-node cluster with RF=3 and 256 tokens, we have seen a
> repair session involving 44 groups of ranges to be repaired. This produces
> 44*3=132 validation requests contacting all the nodes in the cluster. When
> the responses for all these requests start to arrive to the coordinator, each
> containing up to {{repair_session_space}}/3 of Merkle trees, they accumulate
> quicker than they are consumed, greatly exceeding {{repair_session_space}}
> and OOMing the node.
--
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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815257#comment-17815257 ] Brandon Williams commented on CASSANDRA-19335: -- Aha, good find. We can clean that up once CCM is updated. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18824: -- Reviewers: Brandon Williams, Jacek Lewandowski, Jacek Lewandowski (was: Brandon Williams, Jacek Lewandowski) Brandon Williams, Jacek Lewandowski, Jacek Lewandowski (was: Brandon Williams, Jacek Lewandowski) Status: Review In Progress (was: Patch Available) > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18824: -- Status: Ready to Commit (was: Review In Progress) > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815251#comment-17815251 ] Jacek Lewandowski commented on CASSANDRA-18824: --- ok, merging > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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-19375) Link in docs to Achilles Java Driver links to malicious site
PJ Fanning created CASSANDRA-19375: -- Summary: Link in docs to Achilles Java Driver links to malicious site Key: CASSANDRA-19375 URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: PJ Fanning https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java The Achilles link looks dangerous. I tried it and it looked like the link has been taken over by a malicious user. -- 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-19373) 5.0 updates FQL format, but doesn't update version or handle reading old version files
[ https://issues.apache.org/jira/browse/CASSANDRA-19373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-19373: Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: User Report Fix Version/s: 5.0-rc (was: 5.0) Severity: Normal Status: Open (was: Triage Needed) > 5.0 updates FQL format, but doesn't update version or handle reading old > version files > -- > > Key: CASSANDRA-19373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19373 > Project: Cassandra > Issue Type: Bug > Components: Tool/fql >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 5.0-rc, 5.x > > -- 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-19374) CompactionStress tool write data cannot work because of new TCM feature
[
https://issues.apache.org/jira/browse/CASSANDRA-19374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ling Mao updated CASSANDRA-19374:
-
Attachment: compactstree_tcm_code_diff.txt
> CompactionStress tool write data cannot work because of new TCM feature
> ---
>
> Key: CASSANDRA-19374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19374
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress, Transactional Cluster Metadata
>Reporter: Ling Mao
>Priority: Normal
> Fix For: 5.1
>
> Attachments: compactstree_tcm_code_diff.txt
>
>
> CompactionStress tool write data cannot work anymore because of new TCM
> feature
> {code:java}
> ./compaction-stress write -d /tmp/compaction -g 5 -p
> ../cqlstress-example.yaml -t 4
> Cannot write anything to the disk{code}
> It was introduced by the Patch: CEP-21. After applying that patch, this tool
> cannot work
> anymore
> {code:java}
> Implementation of Transactional Cluster Metadata as described in CEP-21
> Hash: ae084237
> {code}
> I attach some key code related diff for further debugging
--
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
