(cassandra-website) branch asf-staging updated (24d473c50 -> 097259427)
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 24d473c50 generate docs for a0b194ad new 097259427 generate docs for a0b194ad 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 (24d473c50) \ N -- N -- N refs/heads/asf-staging (097259427) 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-19776) Spinning trying to capture readers
[
https://issues.apache.org/jira/browse/CASSANDRA-19776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17871180#comment-17871180
]
Cameron Zemek commented on CASSANDRA-19776:
---
Note there are other places in the code that call selectAndReference with
CANONICAL set also that would result in the same issue if there a compaction
ongoing. In fact, I have blacklisted the EstimatedPartitionCount metric as
workaround but still see this spinning occur (yet to trace the origin for
these).
Also another interesting data point all the occurrences of this I have seen are
with TimeWindowCompactionStrategy.
> Spinning trying to capture readers
> --
>
> Key: CASSANDRA-19776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19776
> Project: Cassandra
> Issue Type: Bug
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: extract.log
>
>
> On a handful of clusters we are noticing Spin locks occurring. I traced back
> all the calls to the EstimatedPartitionCount metric (eg.
> org.apache.cassandra.metrics:type=Table,keyspace=testks,scope=testcf,name=EstimatedPartitionCount)
> Using the following patched function:
> {code:java}
> public RefViewFragment selectAndReference(Function Iterable> filter)
> {
> long failingSince = -1L;
> boolean first = true;
> while (true)
> {
> ViewFragment view = select(filter);
> Refs refs = Refs.tryRef(view.sstables);
> if (refs != null)
> return new RefViewFragment(view.sstables, view.memtables,
> refs);
> if (failingSince <= 0)
> {
> failingSince = System.nanoTime();
> }
> else if (System.nanoTime() - failingSince >
> TimeUnit.MILLISECONDS.toNanos(100))
> {
> List released = new ArrayList<>();
> for (SSTableReader reader : view.sstables)
> if (reader.selfRef().globalCount() == 0)
> released.add(reader);
> NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, 1,
> TimeUnit.SECONDS,
> "Spinning trying to capture readers {},
> released: {}, ", view.sstables, released);
> if (first)
> {
> first = false;
> try {
> throw new RuntimeException("Spinning trying to
> capture readers");
> } catch (Exception e) {
> logger.warn("Spin lock stacktrace", e);
> }
> }
> failingSince = System.nanoTime();
> }
> }
> }
> {code}
> Digging into this code I found it will fail if any of the sstables are in
> released state (ie. reader.selfRef().globalCount() == 0).
> See the extract.log for an example of one of these spin lock occurrences.
> Sometimes these spin locks last over 5 minutes. Across the worst cluster with
> this issue, I ran a log processing script that everytime the 'Spinning trying
> to capture readers' was different to previous one it would output if the
> released tables were in Compacting state. Every single occurrence has it spin
> locking with released listing a sstable that is compacting.
> In the extract.log example its spin locking saying that nb-320533-big-Data.db
> has been released. But you can see prior to it spinning that sstable is
> involved in a compaction. The compaction completes at 01:03:36 and the
> spinning stops. nb-320533-big-Data.db is deleted at 01:03:49 along with the
> other 9 sstables involved in the compaction.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17871151#comment-17871151
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 8/5/24 8:01 PM:
---
[~ifesdjeen] [~blerer]
Imagine we process a batch statement
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457].
When we do not use fully qualified table, then isFullyQualified returns false
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634].
Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a
statement in a batch and a user used USE), but then,
qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace
in a batch. So on one hand, we are setting a keyspace of each statement yet
when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it
started to fail some already existing tests where it has not specified fully
qualified statements in a batch while it was using USE and it logged an error
while the test was not prepared for such error logging statement. I think we
should do something like this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null &&
!currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
was (Author: smiklosovic):
[~ifesdjeen] [~blerer]
Imagine we process a batch statement
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457].
When we do not use fully qualified table, then isFullyQualified returns false
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634].
Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a
statement in a batch and a user used USE), but then,
qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace
in a batch. So on one hand, we are setting a keyspace of each statement yet
when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it
started to fail some tests when I have not specified fully qualified statements
in a batch while it was using USE and it logged an error while the test was not
prepared for such error logging statement. I think we should do something like
this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null &&
!currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
>
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17871151#comment-17871151
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 8/5/24 7:59 PM:
---
[~ifesdjeen] [~blerer]
Imagine we process a batch statement
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457].
When we do not use fully qualified table, then isFullyQualified returns false
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634].
Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a
statement in a batch and a user used USE), but then,
qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace
in a batch. So on one hand, we are setting a keyspace of each statement yet
when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it
started to fail some tests when I have not specified fully qualified statements
in a batch while it was using USE and it logged an error while the test was not
prepared for such error logging statement. I think we should do something like
this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null &&
!currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
was (Author: smiklosovic):
[~ifesdjeen] [~blerer]
Imagine we process a batch statement
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457]
When we do not use fully qualified table, then isFullyQualified returns false
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634].
Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a
statement in a batch and a user used USE), but then,
qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace
in a batch. So on one hand, we are setting a keyspace of each statement yet
when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it
started to fail some tests when I have not specified fully qualified statements
in a batch while it was using USE and it logged an error while the test was not
prepared for such error logging statement. I think we should do something like
this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null &&
!currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components:
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17871151#comment-17871151
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
[~ifesdjeen] [~blerer]
Imagine we process a batch statement
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457]
When we do not use fully qualified table, then isFullyQualified returns false
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634].
Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a
statement in a batch and a user used USE), but then,
qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace
in a batch. So on one hand, we are setting a keyspace of each statement yet
when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it
started to fail some tests when I have not specified fully qualified statements
in a batch while it was using USE and it logged an error while the test was not
prepared for such error logging statement. I think we should do something like
this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null &&
!currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-19815) [Analytics] Decouple Cassandra types from Spark types so Cassandra types can be used independently from Spark
[ https://issues.apache.org/jira/browse/CASSANDRA-19815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Berragan updated CASSANDRA-19815: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Reviewers: Francisco Guerrero, Yifan Cai Status: Open (was: Triage Needed) > [Analytics] Decouple Cassandra types from Spark types so Cassandra types can > be used independently from Spark > - > > Key: CASSANDRA-19815 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19815 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Priority: Normal > > The Cassandra types and Spark types are tightly coupled in the same classes, > making it difficult to deserialize Cassandra types without pulling in Spark > as a dependency, We can split out the Spark types into a separate module by > introducing a new TypeConverter that maps Cassandra types to Spark types. > This enables use of the Cassandra types without pulling in Spark and also > opens the possibility of other TypeConverters in the future beyond Spark. -- 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
[PR] Decouple Cassandra types from Spark types so Cassandra types can be u… [cassandra-analytics]
jberragan opened a new pull request, #71: URL: https://github.com/apache/cassandra-analytics/pull/71 …sed independently from Spark -- 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-19815) [Analytics] Decouple Cassandra types from Spark types so Cassandra types can be used independently from Spark
[ https://issues.apache.org/jira/browse/CASSANDRA-19815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Berragan updated CASSANDRA-19815: --- Summary: [Analytics] Decouple Cassandra types from Spark types so Cassandra types can be used independently from Spark (was: https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-19666?filter=allopenissues) > [Analytics] Decouple Cassandra types from Spark types so Cassandra types can > be used independently from Spark > - > > Key: CASSANDRA-19815 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19815 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Priority: Normal > > The Cassandra types and Spark types are tightly coupled in the same classes, > making it difficult to deserialize Cassandra types without pulling in Spark > as a dependency, We can split out the Spark types into a separate module by > introducing a new TypeConverter that maps Cassandra types to Spark types. > This enables use of the Cassandra types without pulling in Spark and also > opens the possibility of other TypeConverters in the future beyond Spark. -- 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-19815) https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-19666?filter=allopenissues
James Berragan created CASSANDRA-19815: -- Summary: https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-19666?filter=allopenissues Key: CASSANDRA-19815 URL: https://issues.apache.org/jira/browse/CASSANDRA-19815 Project: Cassandra Issue Type: Improvement Components: Analytics Library Reporter: James Berragan The Cassandra types and Spark types are tightly coupled in the same classes, making it difficult to deserialize Cassandra types without pulling in Spark as a dependency, We can split out the Spark types into a separate module by introducing a new TypeConverter that maps Cassandra types to Spark types. This enables use of the Cassandra types without pulling in Spark and also opens the possibility of other TypeConverters in the future beyond Spark. -- 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-gocql-driver) branch trunk updated: Update CONTRIBUTING for project's new home
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-gocql-driver.git The following commit(s) were added to refs/heads/trunk by this push: new e83bb39 Update CONTRIBUTING for project's new home e83bb39 is described below commit e83bb39fa76524ed6b375fa9d256ca2b55d4b9df Author: mck AuthorDate: Sat Jun 29 19:07:07 2024 +0200 Update CONTRIBUTING for project's new home patch by Mick Semb Wever; reviewed by Martin Sucha for CASSANDRA-19723 --- CONTRIBUTING.md | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8b49779..0231b06 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,24 +6,39 @@ This guide outlines the process of landing patches in gocql and the general appr ## Background -The goal of the gocql project is to provide a stable and robust CQL driver for Go. gocql is a community driven project that is coordinated by a small team of core developers. +The goal of the gocql project is to provide a stable and robust CQL driver for Go. This is a community driven project that is coordinated by a small team of developers in and around the Apache Cassandra project. For security, governance and administration issues please refer to the Cassandra Project Management Committee. ## Minimum Requirement Checklist The following is a check list of requirements that need to be satisfied in order for us to merge your patch: -* You should raise a pull request to gocql/gocql on Github +* You should raise a pull request to apache/cassandra-gocql-driver on Github * The pull request has a title that clearly summarizes the purpose of the patch * The motivation behind the patch is clearly defined in the pull request summary -* Your name and email have been added to the `AUTHORS` file (for copyright purposes) +* You agree that your contribution is donated to the Apache Software Foundation (appropriate copyright is on all new files) * The patch will merge cleanly -* The test coverage does not fall below the critical threshold (currently 64%) -* The merge commit passes the regression test suite on Travis +* The test coverage does not fall +* The merge commit passes the regression test suite on GitHub Actions * `go fmt` has been applied to the submitted code * Notable changes (i.e. new features or changed behavior, bugfixes) are appropriately documented in CHANGELOG.md, functional changes also in godoc +* A correctly formatted commit message, see below If there are any requirements that can't be reasonably satisfied, please state this either on the pull request or as part of discussion on the mailing list. Where appropriate, the core team may apply discretion and make an exception to these requirements. +## Commit Message + +The Apache Cassandra project has a commit message precendence like +``` + + + patch by ; reviewed by for CASSANDRA-# +``` + +The 'patch by …; reviewed by' line is important. It permits our review-than-commit procedure, allowing commits from non-git-branch patches. It is also parsed to build the project contribulyse statistics found [here](https://nightlies.apache.org/cassandra/devbranch/misc/contribulyze/html/). + + +Background: https://cassandra.apache.org/_/development/how_to_commit.html#tips + ## Beyond The Checklist In addition to stating the hard requirements, there are a bunch of things that we consider when assessing changes to the library. These soft requirements are helpful pointers of how to get a patch landed quicker and with less fuss. @@ -45,12 +60,3 @@ Generally speaking, a pull request can get merged by any one of the project's co ### Supported Features gocql is a low level wire driver for Cassandra CQL. By and large, we would like to keep the functional scope of the library as narrow as possible. We think that gocql should be tight and focused, and we will be naturally skeptical of things that could just as easily be implemented in a higher layer. Inevitably you will come across something that could be implemented in a higher layer, save for a minor change to the core API. In this instance, please strike up a conversation in the Cassan [...] - -## Officially Supported Server Versions - -Currently, the officially supported versions of the Cassandra server include: - -* 1.2.18 -* 2.0.9 - -Chances are that gocql will work with many other versions. If you would like us to support a particular version of Cassandra, please start a conversation about what version you'd like us to consider. We are more likely to accept a new version if you help out by extending the regression suite to cover the new version to be supported. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail:
Re: [PR] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
michaelsembwever merged PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787 -- 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
Re: [PR] Update new contribution agreement from Ghais Issa [cassandra-gocql-driver]
michaelsembwever commented on PR #1792: URL: https://github.com/apache/cassandra-gocql-driver/pull/1792#issuecomment-2269643603 > It is not clear to me whether Árni Dagur and Tushar Das should have an asterisk, since the comments https://github.com/apache/cassandra-gocql-driver/issues/1751#issuecomment-2196472803 and https://github.com/apache/cassandra-gocql-driver/issues/1751#issuecomment-2245661503 both say that they haven't signed the CLA and the top of the NOTICE file says They both expressed (at least I understood) that their work could be used and that signing the CLA didn't seem necessary. That's enough for us, as we're still keeping the copyright in place for work pre-donation. -- 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-19297) Accord: RejectBefore must be up-to-date on joining nodes before ready to coordinate
[ https://issues.apache.org/jira/browse/CASSANDRA-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19297: Fix Version/s: 5.x Source Control Link: https://github.com/apache/cassandra-accord/commit/72f90d2cfd9336d3818260f84a18a60b9aa18542 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Accord: RejectBefore must be up-to-date on joining nodes before ready to > coordinate > --- > > Key: CASSANDRA-19297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19297 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > The exclusive sync point used to join the shard will be known by a majority > of the existing replicas, but in the event the quorum changes and the new > replica has not recorded the exclusive sync point this might in principle > lead to failing to reject a TxnId that should be rejected. > Simple fix, but introduce tests to corroborate this issue, and see if can > reproduce in burn test. -- 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-19297) Accord: RejectBefore must be up-to-date on joining nodes before ready to coordinate
[ https://issues.apache.org/jira/browse/CASSANDRA-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19297: Status: Review In Progress (was: Patch Available) > Accord: RejectBefore must be up-to-date on joining nodes before ready to > coordinate > --- > > Key: CASSANDRA-19297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19297 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > Labels: pull-request-available > > The exclusive sync point used to join the shard will be known by a majority > of the existing replicas, but in the event the quorum changes and the new > replica has not recorded the exclusive sync point this might in principle > lead to failing to reject a TxnId that should be rejected. > Simple fix, but introduce tests to corroborate this issue, and see if can > reproduce in burn test. -- 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-19297) Accord: RejectBefore must be up-to-date on joining nodes before ready to coordinate
[ https://issues.apache.org/jira/browse/CASSANDRA-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-19297: Status: Ready to Commit (was: Review In Progress) > Accord: RejectBefore must be up-to-date on joining nodes before ready to > coordinate > --- > > Key: CASSANDRA-19297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19297 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > Labels: pull-request-available > > The exclusive sync point used to join the shard will be known by a majority > of the existing replicas, but in the event the quorum changes and the new > replica has not recorded the exclusive sync point this might in principle > lead to failing to reject a TxnId that should be rejected. > Simple fix, but introduce tests to corroborate this issue, and see if can > reproduce in burn test. -- 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-accord) branch trunk updated (4c870dc9 -> 72f90d2c)
This is an automated email from the ASF dual-hosted git repository. bdeggleston pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git from 4c870dc9 Accord Journal / Determinism add 72f90d2c Add test around missed bootstrap sync point case No new revisions were added by this update. Summary of changes: .../java/accord/coordinate/TopologyChangeTest.java | 169 - 1 file changed, 165 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19631) Consider autocompletion of in-built functions in CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-19631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19631: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Consider autocompletion of in-built functions in CQLSH > -- > > Key: CASSANDRA-19631 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Dhanush Ananthkar >Priority: Normal > > Why do we not autocomplete native functions in CQLSH shell? I am pretty lost > in what functions are there to choose from without consulting the > documentation. > Additionally, the documentation on [Blob conversion > functions|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#blob-conversion-functions] > could use an example, as done for the other builtins. -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19813: - Status: Ready to Commit (was: Review In Progress) +1 > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19813: - Reviewers: Brandon Williams, Brandon Williams Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17871054#comment-17871054 ] Michael Semb Wever commented on CASSANDRA-19813: Patch - https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/fix-upgrade_through_versions_test-timeouts/5.0 > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Fix Version/s: 5.x > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
michaelsembwever commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1704054428 ## NOTICE: ## @@ -48,7 +48,7 @@ Matt Robenolt Phillip Couto * Niklas Korz Nimi Wariboko Jr -Ghais Issa +Ghais Issa * Review Comment: Good catch, thanks. I got a bit confused bringing all the changes over to https://github.com/apache/cassandra-gocql-driver/pull/1792. Fixed now. -- 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
Re: [PR] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
michaelsembwever commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1704041200 ## CONTRIBUTING.md: ## @@ -6,24 +6,39 @@ This guide outlines the process of landing patches in gocql and the general appr ## Background -The goal of the gocql project is to provide a stable and robust CQL driver for Go. gocql is a community driven project that is coordinated by a small team of core developers. +The goal of the gocql project is to provide a stable and robust CQL driver for Go. This is a community driven project that is coordinated by a small team of developers in and around the Apache Cassandra project. For security, governance and administration issues please refer to the Cassandra Project Management Committee. ## Minimum Requirement Checklist The following is a check list of requirements that need to be satisfied in order for us to merge your patch: -* You should raise a pull request to gocql/gocql on Github +* You should raise a pull request to apache/cassandra-gocql-driver on Github * The pull request has a title that clearly summarizes the purpose of the patch * The motivation behind the patch is clearly defined in the pull request summary -* Your name and email have been added to the `AUTHORS` file (for copyright purposes) +* You agree that your contribution is donated to the Apache Software Foundation (appropriate copyright is on all new files) * The patch will merge cleanly -* The test coverage does not fall below the critical threshold (currently 64%) -* The merge commit passes the regression test suite on Travis +* The test coverage does not fall +* The merge commit passes the regression test suite on GitHub Actions * `go fmt` has been applied to the submitted code * Notable changes (i.e. new features or changed behavior, bugfixes) are appropriately documented in CHANGELOG.md, functional changes also in godoc +* A correctly formatted commit message, see below If there are any requirements that can't be reasonably satisfied, please state this either on the pull request or as part of discussion on the mailing list. Where appropriate, the core team may apply discretion and make an exception to these requirements. +## Commit Message + +The Apache Cassandra project has a commit message precendence like +``` + + + patch by ; reviewed by for CASSANDRA-# +``` + +The 'patch by …; reviewed by' line is important. If enforces our review-than-commit procedure, allowing commits from non-git-branch patches, and is parsed to build the project contribulyse statistics found [here](https://nightlies.apache.org/cassandra/devbranch/misc/contribulyze/html/). Review Comment: Fixed. And a small rewording for clarify. -- 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
Re: [PR] Update new contribution agreement from Ghais Issa [cassandra-gocql-driver]
michaelsembwever commented on PR #1792: URL: https://github.com/apache/cassandra-gocql-driver/pull/1792#issuecomment-2268953133 > Related comment: https://github.com/apache/cassandra-gocql-driver/issues/1751#issuecomment-2189623544 Oh, thanks for point that out, now I see/remember there's others too that have since given their approval. Commit updated… -- 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-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18839:
--
Fix Version/s: 4.0.14
4.1.6
5.0.1
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/b8e08840ee676a4d94f643221627689241e5f51f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.14, 4.1.6, 5.0.1, 5.1
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
>
(cassandra) branch cassandra-4.0 updated (a5767a5834 -> b8e08840ee)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from a5767a5834 Fix schema.cql created by a snapshot after dropping more than one column add b8e08840ee Do not spam log with SSLExceptions No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/transport/ExceptionHandlers.java | 6 ++ 2 files changed, 7 insertions(+) - 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 (b662744af5 -> aa7afeabce)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b662744af5 Prepare debian changelog for 4.1.6 add b8e08840ee Do not spam log with SSLExceptions add aa7afeabce Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/transport/ExceptionHandlers.java | 10 -- src/java/org/apache/cassandra/transport/PreV5Handlers.java | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (2f6efaa986 -> 9679206f74)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 2f6efaa986 Merge branch 'cassandra-5.0' into trunk add b8e08840ee Do not spam log with SSLExceptions add aa7afeabce Merge branch 'cassandra-4.0' into cassandra-4.1 add 85566a6a02 Merge branch 'cassandra-4.1' into cassandra-5.0 new 9679206f74 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 + src/java/org/apache/cassandra/metrics/ClientMetrics.java | 7 +++ .../apache/cassandra/transport/ExceptionHandlers.java| 16 ++-- .../org/apache/cassandra/transport/PreV5Handlers.java| 3 ++- 4 files changed, 24 insertions(+), 3 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.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 9679206f7443328b8688e35f6f09ce284d4bfe21
Merge: 2f6efaa986 85566a6a02
Author: Stefan Miklosovic
AuthorDate: Mon Aug 5 12:25:52 2024 +0200
Merge branch 'cassandra-5.0' into trunk
CHANGES.txt | 1 +
src/java/org/apache/cassandra/metrics/ClientMetrics.java | 7 +++
.../apache/cassandra/transport/ExceptionHandlers.java| 16 ++--
.../org/apache/cassandra/transport/PreV5Handlers.java| 3 ++-
4 files changed, 24 insertions(+), 3 deletions(-)
diff --cc CHANGES.txt
index 30bc56e6c2,13e65ee1f0..5c390dd442
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -120,9 -63,10 +120,10 @@@ Merged from 4.1
* Fix hints delivery for a node going down repeatedly (CASSANDRA-19495)
* Do not go to disk for reading hints file sizes (CASSANDRA-19477)
* Fix system_views.settings to handle array types (CASSANDRA-19475)
- * 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:
++ * Do not spam log with SSLExceptions (CASSANDRA-18839)
* Fix schema.cql created by a snapshot after dropping more than one column
(CASSANDRA-19747)
* UnsupportedOperationException when reducing scope for LCS compactions
(CASSANDRA-19704)
* Make LWT conditions behavior on frozen and non-frozen columns consistent
for null column values (CASSANDRA-19637)
diff --cc src/java/org/apache/cassandra/metrics/ClientMetrics.java
index bc112a0faf,5616571b9a..1df5a23b21
--- a/src/java/org/apache/cassandra/metrics/ClientMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/ClientMetrics.java
@@@ -95,6 -60,6 +95,7 @@@ public final class ClientMetric
private Meter timedOutBeforeProcessing;
private Meter protocolException;
++private Meter sslHandshakeException;
private Meter unknownException;
private Timer queueTime;
@@@ -174,6 -109,6 +175,11 @@@
protocolException.mark();
}
++public void markSSLHandshakeException()
++{
++sslHandshakeException.mark();
++}
++
public void markUnknownException()
{
unknownException.mark();
@@@ -235,6 -149,6 +241,7 @@@
timedOutBeforeProcessing = registerMeter("TimedOutBeforeProcessing");
protocolException = registerMeter("ProtocolException");
++sslHandshakeException = registerMeter("SSLHandshakeException");
unknownException = registerMeter("UnknownException");
initialized = true;
diff --cc src/java/org/apache/cassandra/transport/ExceptionHandlers.java
index 0039bc0e7d,4156342fea..2c28ec21c0
--- a/src/java/org/apache/cassandra/transport/ExceptionHandlers.java
+++ b/src/java/org/apache/cassandra/transport/ExceptionHandlers.java
@@@ -23,6 -23,8 +23,9 @@@ import java.net.SocketAddress
import java.util.Set;
import java.util.concurrent.TimeUnit;
+ import javax.net.ssl.SSLException;
++import javax.net.ssl.SSLHandshakeException;
+
import com.google.common.base.Predicate;
import com.google.common.collect.ImmutableSet;
@@@ -133,6 -135,10 +136,15 @@@ public class ExceptionHandler
ClientMetrics.instance.markUnknownException();
logger.trace("Native exception in client networking", cause);
}
++else if (Throwables.anyCauseMatches(cause, t -> t instanceof
SSLHandshakeException))
++{
++ClientMetrics.instance.markSSLHandshakeException();
++NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, 1,
TimeUnit.MINUTES, "SSLHandshakeException in client networking with peer {} {}",
clientAddress, cause.getMessage());
++}
+ else if (Throwables.anyCauseMatches(cause, t -> t instanceof
SSLException))
+ {
+ NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, 1,
TimeUnit.MINUTES, "SSLException in client networking with peer {} {}",
clientAddress, cause.getMessage());
+ }
else
{
ClientMetrics.instance.markUnknownException();
diff --cc src/java/org/apache/cassandra/transport/PreV5Handlers.java
index fd39edabc1,d8c2067f5b..43cc3e2333
--- a/src/java/org/apache/cassandra/transport/PreV5Handlers.java
+++ b/src/java/org/apache/cassandra/transport/PreV5Handlers.java
@@@ -356,11 -340,11 +356,12 @@@ public class PreV5Handler
// Sometimes it is desirable to ignore exceptions from
specific IPs; such as when security scans are
// running. To avoid polluting logs and metrics, metrics are
not updated when the IP is in the exclude
// list.
-logger.debug("Excluding client exception for {}; address
contained in
(cassandra) branch cassandra-5.0 updated (e2495e182f -> 85566a6a02)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from e2495e182f Merge branch 'cassandra-5.0.0' into cassandra-5.0 add b8e08840ee Do not spam log with SSLExceptions add aa7afeabce Merge branch 'cassandra-4.0' into cassandra-4.1 add 85566a6a02 Merge branch 'cassandra-4.1' into cassandra-5.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 2 ++ src/java/org/apache/cassandra/transport/ExceptionHandlers.java | 10 -- src/java/org/apache/cassandra/transport/PreV5Handlers.java | 3 ++- 3 files changed, 12 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Support of sending queries to the specific node [cassandra-gocql-driver]
martin-sucha commented on PR #1793: URL: https://github.com/apache/cassandra-gocql-driver/pull/1793#issuecomment-2268518112 Should the API allow for other routing preferences? For example only a single data center/rack? Or be extensible to allow targeting a specific shard in the scylladb/gocql fork? Should the API allow to route to a different host during retry, i.e. allow passing a `HostSelectionPolicy` or a similar interface/function? -- 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
[PR] Support of sending queries to the specific node [cassandra-gocql-driver]
worryg0d opened a new pull request, #1793:
URL: https://github.com/apache/cassandra-gocql-driver/pull/1793
# Overview
This PR provides a mechanism that allows users to specify on which node the
query will be executed. It is now a typical use case, but it makes sense with
virtual tables.
For example, when we want to retrieve metrics for a specific node, we have
to send queries to the associated system view of this node.
# Implementation Overview
A new method `SetHost()` for the `Query` allows users to specify the host
(node) on which we have to send the query. It is implemented by adding a new
private interface:
```go
type hostGetter interface {
getHost() *HostInfo
}
```
When the `queryExecutor.executeQuery` is called then it checks if the
provided `ExecutableQuery` implements the `hostGetter` interface as well. We
need this interface to not change the API `ExecutableQuery`. Also, the
`ExecutableQuery` is implemented by `Query` and `Batch` as well, so it is good
to avoid adding redundant methods for `Batch` as well.
So, if provided `ExecutableQuery` implements `hostGetter`, then it
type-asserts it and calls the underlying method to get the host. If the host is
not nil, it wraps the host into `hostIter` func which just returns the
specified host.
When the `Query.host` is set, then the `queryExecutor` host selection policy.
This PR also exposes to users `session.GetHosts()` method which calls the
underlying `session.hostSource.GetHosts()` method.
# Usage Example
Here is an example of retrieving metrics from system_view.cql_metrics for
each node of the cluster:
```go
cluster := NewCluster("127.0.0.1")
session, err := cluster.CreateSession()
if err != nil {
panic(err)
}
defer session.Close()
hosts, err := session.GetHosts()
if err != nil {
panic(err)
}
type cqlMetric struct {
name string
value float64
}
// hostId to []cqlMetric
cqlMetrics := map[string][]cqlMetric{}
for _, host := range hosts {
iter := session.Query("SELECT * FROM system_views.cql_metrics").
SetHost(host).
Iter()
metrics := make([]cqlMetric, 0, iter.NumRows())
metric := cqlMetric{}
for iter.Scan(, ) {
metrics = append(metrics, metric)
}
cqlMetrics[host.HostID()] = metrics
}
```
--
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
Re: [PR] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
martin-sucha commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1703657168 ## CONTRIBUTING.md: ## @@ -6,24 +6,39 @@ This guide outlines the process of landing patches in gocql and the general appr ## Background -The goal of the gocql project is to provide a stable and robust CQL driver for Go. gocql is a community driven project that is coordinated by a small team of core developers. +The goal of the gocql project is to provide a stable and robust CQL driver for Go. This is a community driven project that is coordinated by a small team of developers in and around the Apache Cassandra project. For security, governance and administration issues please refer to the Cassandra Project Management Committee. ## Minimum Requirement Checklist The following is a check list of requirements that need to be satisfied in order for us to merge your patch: -* You should raise a pull request to gocql/gocql on Github +* You should raise a pull request to apache/cassandra-gocql-driver on Github * The pull request has a title that clearly summarizes the purpose of the patch * The motivation behind the patch is clearly defined in the pull request summary -* Your name and email have been added to the `AUTHORS` file (for copyright purposes) +* You agree that your contribution is donated to the Apache Software Foundation (appropriate copyright is on all new files) * The patch will merge cleanly -* The test coverage does not fall below the critical threshold (currently 64%) -* The merge commit passes the regression test suite on Travis +* The test coverage does not fall +* The merge commit passes the regression test suite on GitHub Actions * `go fmt` has been applied to the submitted code * Notable changes (i.e. new features or changed behavior, bugfixes) are appropriately documented in CHANGELOG.md, functional changes also in godoc +* A correctly formatted commit message, see below If there are any requirements that can't be reasonably satisfied, please state this either on the pull request or as part of discussion on the mailing list. Where appropriate, the core team may apply discretion and make an exception to these requirements. +## Commit Message + +The Apache Cassandra project has a commit message precendence like +``` + + + patch by ; reviewed by for CASSANDRA-# +``` + +The 'patch by …; reviewed by' line is important. If enforces our review-than-commit procedure, allowing commits from non-git-branch patches, and is parsed to build the project contribulyse statistics found [here](https://nightlies.apache.org/cassandra/devbranch/misc/contribulyze/html/). Review Comment: Typo: `If`→`It` -- 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
Re: [PR] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
martin-sucha commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1703654322 ## NOTICE: ## @@ -48,7 +48,7 @@ Matt Robenolt Phillip Couto * Niklas Korz Nimi Wariboko Jr -Ghais Issa +Ghais Issa * Review Comment: Thank you! There are still two other entries in NOTICE changed by this pull request. -- 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-19779) direct IO support is always evaluated to false upon the very first start of a node
[
https://issues.apache.org/jira/browse/CASSANDRA-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19779:
--
Fix Version/s: 5.0-rc2
5.0.1
5.1
(was: 5.0-rc)
Source Control Link:
https://github.com/apache/cassandra/commit/5ab976d796471a1ecdf3596a148a3e4b8c1a982e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> direct IO support is always evaluated to false upon the very first start of a
> node
> --
>
> Key: CASSANDRA-19779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19779
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc2, 5.0.1, 5.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When I extract the distribution tarball and I want to use tools in tools/bin,
> there is this warn log visible every time for tools when they are started
> (does not happen on "help" command, obviously)
> {code:java}
> WARN 14:25:11,835 Unable to determine block size for commit log directory:
> null {code}
> This is because we introduced this (1) in CASSANDRA-18464
> What that does is that it will go and try to create a temporary file in
> commit log directory to get "block size" for a "file store" that file is in.
> The problem with that is that when we just extract a tarball and run the
> tools - Cassandra was never started - then such commit log directory does not
> exist yet, so it tries to create a temporary file in a non-existing
> directory, which fails, hence the log message.
> The fix is to check if commitlog dir exists and return / skip the resolution
> of block size if it does not.
> Another approach might be to check if this is executed in the context of a
> tool and skip it from resolution altogether. The problem with this is that
> not all tools we have in bin/log call DatabaseDescriptor.
> toolInitialization() so we might combine these two.
> (1)
> [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1455-L1462]
--
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-5.0.0 updated (17c92cef09 -> 5ab976d796)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 17c92cef09 Increment version to 5.0-rc2 (test dockerfile) add 5ab976d796 Fix direct IO support always being evaluated to false upon the first start of a node No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/config/DatabaseDescriptor.java | 15 +- .../cassandra/config/DatabaseDescriptorTest.java | 60 +- .../org/apache/cassandra/repair/FuzzTestBase.java | 3 ++ 4 files changed, 53 insertions(+), 26 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 (7903ce2727 -> e2495e182f)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7903ce2727 Deprecate and ignore use_deterministic_table_id add 5ab976d796 Fix direct IO support always being evaluated to false upon the first start of a node add e2495e182f Merge branch 'cassandra-5.0.0' into cassandra-5.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/config/DatabaseDescriptor.java | 15 +- .../cassandra/config/DatabaseDescriptorTest.java | 60 +- .../org/apache/cassandra/repair/FuzzTestBase.java | 3 ++ 4 files changed, 53 insertions(+), 26 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (9fb141ffcc -> 2f6efaa986)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 9fb141ffcc Change log level when sending message during messaging service shutdown. add 5ab976d796 Fix direct IO support always being evaluated to false upon the first start of a node add e2495e182f Merge branch 'cassandra-5.0.0' into cassandra-5.0 add 2f6efaa986 Merge branch 'cassandra-5.0' into trunk No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/config/DatabaseDescriptor.java | 15 +- .../cassandra/config/DatabaseDescriptorTest.java | 60 +- .../org/apache/cassandra/repair/FuzzTestBase.java | 3 ++ 4 files changed, 53 insertions(+), 26 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870881#comment-17870881 ] Cameron Zemek commented on CASSANDRA-18543: --- [~Aburadeh] can you refer to https://issues.apache.org/jira/browse/CASSANDRA-19580 to see if that is what you are running into. > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.16, 4.0.11, 4.1.3, 5.0-alpha1, 5.0 > > Attachments: gossip.patch, gossip4.patch > > Time Spent: 1h > Remaining Estimate: 0h > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > This is problem for a number of large clusters for our customers. The cluster > has quorum but due to this issue a node restart is causing a bunch of query > errors. > My initial solution to this was to only check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP in markAlive. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. I could not reliability reproduce this > but think its worth providing a way to override these hardcoded values. -- 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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870871#comment-17870871
]
Arun Ganesh commented on CASSANDRA-19583:
-
Bumping this up.
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870866#comment-17870866 ] Michael Semb Wever commented on CASSANDRA-19813: In `dtest-upgrade-large` (and variants) there are only 57 tests (actually 53, as four are template tests that need to be "generated"). When splits are "empty" there are supposed to only run the first test found in the test_list.txt file, so that some test results exist (and don't fail the build): https://github.com/apache/cassandra/blob/cassandra-5.0/.build/run-tests.sh#L135-L137 versus https://github.com/apache/cassandra/blob/cassandra-5.0/.build/run-python-dtests.sh#L148 Something changed, so the "empty" splits are now running many more tests. Tests themselves are not taking longer. Reducing the split size from 64 to 32 validated this: - https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/40/ - [^Cassandra-devbranch-5_40_ci_summary.html] [^Cassandra-devbranch-5_40_results_details.tar.xz] > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever reassigned CASSANDRA-19813: -- Assignee: Michael Semb Wever > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: Cassandra-devbranch-5_40_ci_summary.html Cassandra-devbranch-5_40_results_details.tar.xz > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: Cassandra-devbranch-5_40_ci_summary.html, > Cassandra-devbranch-5_40_results_details.tar.xz, > test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, > test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, > test_rolling_upgrade.257.good.log, test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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 burn-test-stability updated: update accord
This is an automated email from the ASF dual-hosted git repository. benedict pushed a commit to branch burn-test-stability in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/burn-test-stability by this push: new 6cf967f80e update accord 6cf967f80e is described below commit 6cf967f80e801d86c08eada2f8c53b9a9a916383 Author: Benedict Elliott Smith AuthorDate: Sun Aug 4 21:20:06 2024 +0300 update accord --- modules/accord | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/accord b/modules/accord index d1604efe37..862e7a21ca 16 --- a/modules/accord +++ b/modules/accord @@ -1 +1 @@ -Subproject commit d1604efe375ab0baeb8505477a896572af83805b +Subproject commit 862e7a21caef55f4cab6e6f8868d295800973abf - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: test_rolling_upgrade.257.good.log test_rolling_upgrade.261-2.log test_rolling_upgrade.261-1.log > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log, > test_rolling_upgrade.261-1.log, test_rolling_upgrade.261-2.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: (was: test_rolling_upgrade.257.good.log) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: (was: test_rolling_upgrade.261-2.log) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: (was: test_rolling_upgrade.261-1.log) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870854#comment-17870854
]
Michael Semb Wever commented on CASSANDRA-19813:
The tests found in each split has changed.
{{`upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade`}}
was previously (when things were working) found in split 9/64.
The attached good log for run 257 updated accordingly.
> timeout on
> upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
> -
>
> Key: CASSANDRA-19813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19813
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0-rc
>
> Attachments: test_rolling_upgrade.261-1.log,
> test_rolling_upgrade.261-2.log, test_rolling_upgrade.122.log,
> test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log,
> test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log
>
>
> The
> upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
> test is taking longer than usual.
> CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now.
> Our 5.0-rc testing results are tainted because these time outs always abort
> the 5.0 pipeline runs.
> It looks like that split is taking 16x times as long now…
> This appears to be caused from either/both
> -
> https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588
> -
> https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa
> Example of good run.
> [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o)
> Examples of bad runs.
> [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log],
> [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log]
> (internal ci)
> [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log]
> (ci-cassandra.a.o)
--
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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Description: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] (internal ci) [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] (ci-cassandra.a.o) was: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] (internal ci) [^ test_rolling_upgrade.261-1.log] , [^ test_rolling_upgrade.261-2.log] (ci-cassandra.a.o) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log, test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^test_rolling_upgrade.261-1.log] , [^test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Attachment: test_rolling_upgrade.261-1.log test_rolling_upgrade.261-2.log > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log, test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Description: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] (internal ci) [^ test_rolling_upgrade.261-1.log] , [^ test_rolling_upgrade.261-2.log] (ci-cassandra.a.o) was: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.261-1.log, > test_rolling_upgrade.261-2.log, test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o) > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > (internal ci) > [^ test_rolling_upgrade.261-1.log] , [^ test_rolling_upgrade.261-2.log] > (ci-cassandra.a.o) -- 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-19814) UDT codec decode is too restrictive in decoding of unknown fields
[
https://issues.apache.org/jira/browse/CASSANDRA-19814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870704#comment-17870704
]
Dmitry Konstantinov commented on CASSANDRA-19814:
-
https://github.com/apache/cassandra-java-driver/pull/1942
> UDT codec decode is too restrictive in decoding of unknown fields
> -
>
> Key: CASSANDRA-19814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19814
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current UDT code logic in driver 4.x expects the number of UDT fields
> exactly equal to the number of fields in the schema version used to create
> the codec.
> As a result it makes applications less friendly to a live upgrade logic when
> we change DB schema and do a rolling restart of applications to switch from
> an old app version to a new one. In this scenario we can add a new field to
> UDT (backward compatible change) and a new application version can write this
> UDT with a new field filled but the old application version will fail to
> decode such UDT with the extra unknown field.
> Driver 3.x UDT codec has a different behaviour - the UDT codec logic reads
> known UDT fields received from network and ignores the unknown tail, which
> makes in tolerant to such schema changes:
> https://github.com/apache/cassandra-java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/TypeCodec.java#L2202
> A code example to illustrate the issue:
> Schema
> {code:java}
> CREATE TYPE test_keyspace.basicInfoInner (
> weight text,
> height text
> );
> CREATE TYPE test_keyspace.basicInfo (
> birthday timestamp,
> nationality text,
> inner frozen
> );
> CREATE TABLE test_keyspace.tableWithUdt
> (
> id varchar,
> value frozen>,
> PRIMARY KEY (id)
> ); {code}
> Code:
> {code:java}
> CqlSession session = getSession();
> UdtCodec udtCodec = new UdtCodec(userDefinedType);
> TypeCodec> listOfUdtCodec = TypeCodecs.listOf(udtCodec);
> {
> ResultSet resultSet = session.execute("select id, value from
> tableWithUdt");
> for (Row row : resultSet) {
> String id = row.getString(0);
> List udtValueList = row.get(1, listOfUdtCodec);
> }
> }
> session.execute("ALTER TYPE basicInfo ADD details text");
> session.execute("INSERT INTO tableWithUdt (id, value) VALUES ('4', [\n" +
> " { birthday : '1993-06-18', " +
> " nationality : 'New Zealand', " +
> " inner: { weight : '70', height : '70' } " +
> " },\n" +
> " { birthday : '1993-06-19', " +
> " nationality : null, " +
> " inner: { weight : '70', height : null }, " +
> " details: 'added details'" + // <=== insert a value for the new
> added UDT field
> " }\n" +
> " ])");
> {
> ResultSet resultSet = session.execute("select id, value from
> tableWithUdt");
> for (Row row : resultSet) {
> String id = row.getString(0);
> // UdtCodec throws IllegalArgumentException: Too many fields in
> encoded UDT value, expected 3
> List udtValueList = row.get(1, listOfUdtCodec);
> }
> }
> private static UserDefinedType getUserDefinedType(CqlSession session, String
> udtName) {
> return session.getMetadata()
> .getKeyspace(session.getKeyspace().orElseThrow(() -> new
> IllegalArgumentException("Udt name " + udtName + " can't be loaded due to
> null keyspace")))
> .orElseThrow(() -> new IllegalArgumentException("Metadata is not
> found"))
> .getUserDefinedType(udtName)
> .orElseThrow(() -> new IllegalArgumentException("Udt name " +
> udtName + " isn't found"));
> }
> {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] [Commented] (CASSANDRA-19814) UDT codec decode is too restrictive in decoding of unknown fields
[
https://issues.apache.org/jira/browse/CASSANDRA-19814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870702#comment-17870702
]
Dmitry Konstantinov commented on CASSANDRA-19814:
-
I am going to share a patch which makes UDT codec behaviour for 4.x driver
similar to 3.x version.
> UDT codec decode is too restrictive in decoding of unknown fields
> -
>
> Key: CASSANDRA-19814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19814
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
>
> The current UDT code logic in driver 4.x expects the number of UDT fields
> exactly equal to the number of fields in the schema version used to create
> the codec.
> As a result it makes applications less friendly to a live upgrade logic when
> we change DB schema and do a rolling restart of applications to switch from
> an old app version to a new one. In this scenario we can add a new field to
> UDT (backward compatible change) and a new application version can write this
> UDT with a new field filled but the old application version will fail to
> decode such UDT with the extra unknown field.
> Driver 3.x UDT codec has a different behaviour - the UDT codec logic reads
> known UDT fields received from network and ignores the unknown tail, which
> makes in tolerant to such schema changes:
> https://github.com/apache/cassandra-java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/TypeCodec.java#L2202
> A code example to illustrate the issue:
> Schema
> {code:java}
> CREATE TYPE test_keyspace.basicInfoInner (
> weight text,
> height text
> );
> CREATE TYPE test_keyspace.basicInfo (
> birthday timestamp,
> nationality text,
> inner frozen
> );
> CREATE TABLE test_keyspace.tableWithUdt
> (
> id varchar,
> value frozen>,
> PRIMARY KEY (id)
> ); {code}
> Code:
> {code:java}
> CqlSession session = getSession();
> UdtCodec udtCodec = new UdtCodec(userDefinedType);
> TypeCodec> listOfUdtCodec = TypeCodecs.listOf(udtCodec);
> {
> ResultSet resultSet = session.execute("select id, value from
> tableWithUdt");
> for (Row row : resultSet) {
> String id = row.getString(0);
> List udtValueList = row.get(1, listOfUdtCodec);
> }
> }
> session.execute("ALTER TYPE basicInfo ADD details text");
> session.execute("INSERT INTO tableWithUdt (id, value) VALUES ('4', [\n" +
> " { birthday : '1993-06-18', " +
> " nationality : 'New Zealand', " +
> " inner: { weight : '70', height : '70' } " +
> " },\n" +
> " { birthday : '1993-06-19', " +
> " nationality : null, " +
> " inner: { weight : '70', height : null }, " +
> " details: 'added details'" + // <=== insert a value for the new
> added UDT field
> " }\n" +
> " ])");
> {
> ResultSet resultSet = session.execute("select id, value from
> tableWithUdt");
> for (Row row : resultSet) {
> String id = row.getString(0);
> // UdtCodec throws IllegalArgumentException: Too many fields in
> encoded UDT value, expected 3
> List udtValueList = row.get(1, listOfUdtCodec);
> }
> }
> private static UserDefinedType getUserDefinedType(CqlSession session, String
> udtName) {
> return session.getMetadata()
> .getKeyspace(session.getKeyspace().orElseThrow(() -> new
> IllegalArgumentException("Udt name " + udtName + " can't be loaded due to
> null keyspace")))
> .orElseThrow(() -> new IllegalArgumentException("Metadata is not
> found"))
> .getUserDefinedType(udtName)
> .orElseThrow(() -> new IllegalArgumentException("Udt name " +
> udtName + " isn't found"));
> }
> {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] [Created] (CASSANDRA-19814) UDT codec decode is too restrictive in decoding of unknown fields
Dmitry Konstantinov created CASSANDRA-19814:
---
Summary: UDT codec decode is too restrictive in decoding of
unknown fields
Key: CASSANDRA-19814
URL: https://issues.apache.org/jira/browse/CASSANDRA-19814
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Dmitry Konstantinov
Assignee: Dmitry Konstantinov
The current UDT code logic in driver 4.x expects the number of UDT fields
exactly equal to the number of fields in the schema version used to create the
codec.
As a result it makes applications less friendly to a live upgrade logic when we
change DB schema and do a rolling restart of applications to switch from an old
app version to a new one. In this scenario we can add a new field to UDT
(backward compatible change) and a new application version can write this UDT
with a new field filled but the old application version will fail to decode
such UDT with the extra unknown field.
Driver 3.x UDT codec has a different behaviour - the UDT codec logic reads
known UDT fields received from network and ignores the unknown tail, which
makes in tolerant to such schema changes:
https://github.com/apache/cassandra-java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/TypeCodec.java#L2202
A code example to illustrate the issue:
Schema
{code:java}
CREATE TYPE test_keyspace.basicInfoInner (
weight text,
height text
);
CREATE TYPE test_keyspace.basicInfo (
birthday timestamp,
nationality text,
inner frozen
);
CREATE TABLE test_keyspace.tableWithUdt
(
id varchar,
value frozen>,
PRIMARY KEY (id)
); {code}
Code:
{code:java}
CqlSession session = getSession();
UdtCodec udtCodec = new UdtCodec(userDefinedType);
TypeCodec> listOfUdtCodec = TypeCodecs.listOf(udtCodec);
{
ResultSet resultSet = session.execute("select id, value from tableWithUdt");
for (Row row : resultSet) {
String id = row.getString(0);
List udtValueList = row.get(1, listOfUdtCodec);
}
}
session.execute("ALTER TYPE basicInfo ADD details text");
session.execute("INSERT INTO tableWithUdt (id, value) VALUES ('4', [\n" +
" { birthday : '1993-06-18', " +
" nationality : 'New Zealand', " +
" inner: { weight : '70', height : '70' } " +
" },\n" +
" { birthday : '1993-06-19', " +
" nationality : null, " +
" inner: { weight : '70', height : null }, " +
" details: 'added details'" + // <=== insert a value for the new
added UDT field
" }\n" +
" ])");
{
ResultSet resultSet = session.execute("select id, value from tableWithUdt");
for (Row row : resultSet) {
String id = row.getString(0);
// UdtCodec throws IllegalArgumentException: Too many fields in
encoded UDT value, expected 3
List udtValueList = row.get(1, listOfUdtCodec);
}
}
private static UserDefinedType getUserDefinedType(CqlSession session, String
udtName) {
return session.getMetadata()
.getKeyspace(session.getKeyspace().orElseThrow(() -> new
IllegalArgumentException("Udt name " + udtName + " can't be loaded due to null
keyspace")))
.orElseThrow(() -> new IllegalArgumentException("Metadata is not
found"))
.getUserDefinedType(udtName)
.orElseThrow(() -> new IllegalArgumentException("Udt name " +
udtName + " isn't found"));
}
{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] [Commented] (CASSANDRA-19758) Accord: CommandsForKey should self-prune
[ https://issues.apache.org/jira/browse/CASSANDRA-19758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870696#comment-17870696 ] Benedict Elliott Smith commented on CASSANDRA-19758: Similarly, ShortReadProtectionTest fails on cep-15-accord with transactional_mode=full, so I will ignore these failures also. > Accord: CommandsForKey should self-prune > > > Key: CASSANDRA-19758 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19758 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Priority: Normal > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > > CommandsForKey should periodically self-prune, so as to continue functioning > well in-between garbage collections. This is a bit complicated, as once we > prune we are left with potentially incomplete information, and have to > sometimes load per-command information from disk. But the payoff is ensuring > CommandsForKey objects - which drive the majority of the state machine - are > kept to a reasonable size. -- 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-19758) Accord: CommandsForKey should self-prune
[
https://issues.apache.org/jira/browse/CASSANDRA-19758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870684#comment-17870684
]
Benedict Elliott Smith commented on CASSANDRA-19758:
AccordIncrementalRepair test failures appear to predate this patch -
{{txnRepairTest}} is failing today, but it fails due to
{{WriteTimeoutException}}. It now completes the transaction successfully, but
there is a follow-up problem that leaves the cluster in a bad state for the
other tests. If they are run in isolation they succeed.
(Still investigating other failures and test history)
> Accord: CommandsForKey should self-prune
>
>
> Key: CASSANDRA-19758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19758
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> CommandsForKey should periodically self-prune, so as to continue functioning
> well in-between garbage collections. This is a bit complicated, as once we
> prune we are left with potentially incomplete information, and have to
> sometimes load per-command information from disk. But the payoff is ensuring
> CommandsForKey objects - which drive the majority of the state machine - are
> kept to a reasonable size.
--
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-19804) Flakey test upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD#test_rolling_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-19804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19804:
---
Fix Version/s: 5.1
(was: 5.1-alpha1)
> Flakey test
> upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD#test_rolling_upgrade
> -
>
> Key: CASSANDRA-19804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19804
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code}
> ERRORS
>
> _ ERROR at teardown of
> TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD.test_rolling_upgrade _
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node3] 'ERROR [InternalResponseStage:3] 2024-07-26 04:35:12,345
> MessagingService.java:509 - Cannot send the message (from:/127.0.0.3:7000,
> type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to /127.0.0.1:7000, as messaging
> service is shutting down', [node3] 'ERROR [InternalResponseStage:4]
> 2024-07-26 04:35:27,412 MessagingService.java:509 - Cannot send the message
> (from:/127.0.0.3:7000, type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to
> /127.0.0.1:7000, as messaging service is shutting down']
> {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-19807) [Analytics] Improve the core bulk reader test system to match actual and expected rows by concatenating the partition keys with the serialized hex string instead of
[ https://issues.apache.org/jira/browse/CASSANDRA-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-19807: -- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-analytics/commit/3023a204c8ef16f886bd3dc219f7534b7edbaf2a Resolution: Fixed Status: Resolved (was: Ready to Commit) Merged into trunk as [3023a204|https://github.com/apache/cassandra-analytics/commit/3023a204c8ef16f886bd3dc219f7534b7edbaf2a] > [Analytics] Improve the core bulk reader test system to match actual and > expected rows by concatenating the partition keys with the serialized hex > string instead of utf-8 string > - > > Key: CASSANDRA-19807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19807 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Low > Fix For: NA > > Time Spent: 20m > Remaining Estimate: 0h > > The current test system for the bulk reader matches actual and expected rows > by building a utf-8 string of the concatenated partition key(s), it would be > better to match on the hex string of the serialized bytes to avoid the > current custom string builder implementation. -- 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-19807: Improve the core bulk reader test system to match actual and expected rows by concatenating the partition keys with the serialized hex stri
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 3023a20 CASSANDRA-19807: Improve the core bulk reader test system to
match actual and expected rows by concatenating the partition keys with the
serialized hex string instead of utf-8 string (#70)
3023a20 is described below
commit 3023a204c8ef16f886bd3dc219f7534b7edbaf2a
Author: jberragan
AuthorDate: Sat Aug 3 07:51:52 2024 +0100
CASSANDRA-19807: Improve the core bulk reader test system to match actual
and expected rows by concatenating the partition keys with the serialized hex
string instead of utf-8 string (#70)
Patch by James Berragan; Reviewed by Francisco Guerrero, Yifan Cai for
CASSANDRA-19807
---
.../cassandra/spark/utils/test/TestSchema.java | 64 +++---
.../apache/cassandra/spark/data/types/Decimal.java | 2 +-
2 files changed, 8 insertions(+), 58 deletions(-)
diff --git
a/cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/test/TestSchema.java
b/cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/test/TestSchema.java
index 0949940..31b1398 100644
---
a/cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/test/TestSchema.java
+++
b/cassandra-bridge/src/main/java/org/apache/cassandra/spark/utils/test/TestSchema.java
@@ -19,16 +19,13 @@
package org.apache.cassandra.spark.utils.test;
-import java.math.BigDecimal;
-import java.math.RoundingMode;
+import java.nio.ByteBuffer;
import java.nio.file.Path;
-import java.sql.Timestamp;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
import java.util.Comparator;
-import java.util.Date;
import java.util.List;
import java.util.Map;
import java.util.Objects;
@@ -56,6 +53,7 @@ import org.apache.spark.sql.catalyst.InternalRow;
import org.apache.spark.sql.catalyst.expressions.GenericInternalRow;
import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;
+import org.apache.cassandra.spark.utils.ByteBufferUtils;
/**
* Helper class to create and test various schemas
@@ -729,70 +727,22 @@ public final class TestSchema
CqlField.CqlType type = key < partitionKeys.size()
? partitionKeys.get(key).type()
: clusteringKeys.get(key -
partitionKeys.size()).type();
-str.append(toString(type, get(key))).append(":");
+str.append(toHexString(type, get(key))).append(":");
}
return str.toString();
}
-private String toString(CqlField.CqlType type, Object key)
+private String toHexString(CqlField.CqlType type, Object value)
{
-if (key instanceof BigDecimal)
-{
-return ((BigDecimal) key).setScale(8,
RoundingMode.CEILING).toPlainString();
-}
-else if (key instanceof Timestamp)
-{
-return new Date(((Timestamp) key).getTime()).toString();
-}
-else if (key instanceof Object[])
-{
-return String.format("[%s]", Arrays.stream((Object[]) key)
- .map(value ->
toString(type, value))
-
.collect(Collectors.joining(", ")));
-}
-else if (key instanceof Map)
-{
-CqlField.CqlType innerType = getFrozenInnerType(type);
-if (innerType instanceof CqlField.CqlMap)
-{
-CqlField.CqlMap mapType = (CqlField.CqlMap) innerType;
-return ((Map) key).entrySet()
-.stream()
-.sorted((Comparator>) (first,
second) ->
-mapType.keyType().compare(first.getKey(),
second.getKey()))
-.map(Map.Entry::getValue)
-.collect(Collectors.toList())
-.toString();
-}
-return ((Map) key).entrySet().stream().collect(
-Collectors.toMap(entry -> toString(innerType,
entry.getKey()),
- entry -> toString(innerType,
entry.getValue(.toString();
-}
-else if (key instanceof Collection)
-{
-CqlField.CqlType innerType = ((CqlField.CqlCollection)
getFrozenInnerType(type)).type();
-return ((Collection) key).stream()
-.sorted(innerType)
-.map(value -> toString(innerType,
value))
-
Re: [PR] CASSANDRA-19807: Improve the core bulk reader test system to match actual and expected… [cassandra-analytics]
yifan-c merged PR #70: URL: https://github.com/apache/cassandra-analytics/pull/70 -- 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] (CASSANDRA-19807) [Analytics] Improve the core bulk reader test system to match actual and expected rows by concatenating the partition keys with the serialized hex string instead o
[ https://issues.apache.org/jira/browse/CASSANDRA-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870667#comment-17870667 ] Yifan Cai commented on CASSANDRA-19807: --- +1 > [Analytics] Improve the core bulk reader test system to match actual and > expected rows by concatenating the partition keys with the serialized hex > string instead of utf-8 string > - > > Key: CASSANDRA-19807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19807 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > The current test system for the bulk reader matches actual and expected rows > by building a utf-8 string of the concatenated partition key(s), it would be > better to match on the hex string of the serialized bytes to avoid the > current custom string builder implementation. -- 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-19807) [Analytics] Improve the core bulk reader test system to match actual and expected rows by concatenating the partition keys with the serialized hex string instead of
[ https://issues.apache.org/jira/browse/CASSANDRA-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-19807: -- Status: Ready to Commit (was: Review In Progress) > [Analytics] Improve the core bulk reader test system to match actual and > expected rows by concatenating the partition keys with the serialized hex > string instead of utf-8 string > - > > Key: CASSANDRA-19807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19807 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > The current test system for the bulk reader matches actual and expected rows > by building a utf-8 string of the concatenated partition key(s), it would be > better to match on the hex string of the serialized bytes to avoid the > current custom string builder implementation. -- 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) 02/04: burn test stability: wip
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch burn-test-stability
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 64451dde91fcb17784bec7507192aee4a862b015
Author: Benedict Elliott Smith
AuthorDate: Fri Aug 2 15:46:53 2024 +0100
burn test stability: wip
---
.gitmodules| 2 +-
modules/accord | 2 +-
.../service/accord/AccordConfigurationService.java | 1 +
.../service/accord/AccordFetchCoordinator.java | 6 +++-
.../service/accord/AccordObjectSizes.java | 16 +-
.../service/accord/api/AccordTopologySorter.java | 3 +-
.../accord/serializers/CommandSerializers.java | 6 +---
.../service/accord/serializers/DepsSerializer.java | 8 ++---
.../service/accord/serializers/KeySerializers.java | 36 ++
.../accord/serializers/TopologySerializers.java| 4 ++-
.../cassandra/service/accord/txn/TxnRead.java | 16 --
.../cassandra/service/accord/txn/TxnUpdate.java| 9 ++
.../accord/txn/UnrecoverableRepairUpdate.java | 7 +
.../cassandra/utils/CollectionSerializers.java | 11 +++
14 files changed, 75 insertions(+), 52 deletions(-)
diff --git a/.gitmodules b/.gitmodules
index fc9b7c0807..c35fa2db30 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,4 +1,4 @@
[submodule "modules/accord"]
path = modules/accord
url = https://github.com/belliottsmith/cassandra-accord.git
- branch = exclusive-sync-point-fix
+ branch = burn-test-stability
diff --git a/modules/accord b/modules/accord
index 1c8b89da1f..ce6e7a514d 16
--- a/modules/accord
+++ b/modules/accord
@@ -1 +1 @@
-Subproject commit 1c8b89da1fe6afd4f8691b8fe8328091055dedc2
+Subproject commit ce6e7a514de1d4b6ad1c290df423b831664fd535
diff --git
a/src/java/org/apache/cassandra/service/accord/AccordConfigurationService.java
b/src/java/org/apache/cassandra/service/accord/AccordConfigurationService.java
index 1e6cb1d769..a990f1b591 100644
---
a/src/java/org/apache/cassandra/service/accord/AccordConfigurationService.java
+++
b/src/java/org/apache/cassandra/service/accord/AccordConfigurationService.java
@@ -25,6 +25,7 @@ import java.util.stream.Collectors;
import javax.annotation.Nullable;
import com.google.common.annotations.VisibleForTesting;
+import com.google.common.collect.ImmutableSortedSet;
import com.google.common.collect.Sets;
import accord.impl.AbstractConfigurationService;
diff --git
a/src/java/org/apache/cassandra/service/accord/AccordFetchCoordinator.java
b/src/java/org/apache/cassandra/service/accord/AccordFetchCoordinator.java
index 088c6c1331..e4ad2aa559 100644
--- a/src/java/org/apache/cassandra/service/accord/AccordFetchCoordinator.java
+++ b/src/java/org/apache/cassandra/service/accord/AccordFetchCoordinator.java
@@ -35,6 +35,7 @@ import accord.local.CommandStore;
import accord.local.Node;
import accord.local.SafeCommandStore;
import accord.primitives.PartialTxn;
+import accord.primitives.Participants;
import accord.primitives.Range;
import accord.primitives.Ranges;
import accord.primitives.Routable;
@@ -290,6 +291,9 @@ public class AccordFetchCoordinator extends
AbstractFetchCoordinator implements
@Override
public Read slice(Ranges ranges) { return new StreamingRead(to,
this.ranges.slice(ranges)); }
+@Override
+public Read intersecting(Participants participants) { return new
StreamingRead(to, this.ranges.intersecting(ranges)); }
+
@Override
public Read merge(Read other) { throw new
UnsupportedOperationException(); }
}
@@ -383,7 +387,7 @@ public class AccordFetchCoordinator extends
AbstractFetchCoordinator implements
protected PartialTxn rangeReadTxn(Ranges ranges)
{
StreamingRead read = new
StreamingRead(FBUtilities.getBroadcastAddressAndPort(), ranges);
-return new PartialTxn.InMemory(ranges, Txn.Kind.Read, ranges, read,
noopQuery, null);
+return new PartialTxn.InMemory(Txn.Kind.Read, ranges, read, noopQuery,
null);
}
@Override
diff --git
a/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
b/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
index d3cd7a34fd..46e0d8c158 100644
--- a/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
+++ b/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
@@ -137,7 +137,7 @@ public class AccordObjectSizes
return EMPTY_ROUTING_KEYS_SIZE + routingKeysOnly(keys);
}
-private static final long EMPTY_FULL_KEY_ROUTE_SIZE = measure(new
FullKeyRoute(new TokenKey(null, null), true, new RoutingKey[0]));
+private static final long EMPTY_FULL_KEY_ROUTE_SIZE = measure(new
FullKeyRoute(new TokenKey(null, null), new RoutingKey[0]));
public static long fullKeyRoute(FullKeyRoute route)
{
return
(cassandra) 04/04: fix compilation
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch burn-test-stability
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 97c129669744c738ac1a5630b04c51e60e4149c0
Author: Benedict Elliott Smith
AuthorDate: Fri Aug 2 22:47:32 2024 +0100
fix compilation
---
modules/accord | 2 +-
.../org/apache/cassandra/index/accord/CheckpointIntervalArrayIndex.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/modules/accord b/modules/accord
index 5e80957a6d..d1604efe37 16
--- a/modules/accord
+++ b/modules/accord
@@ -1 +1 @@
-Subproject commit 5e80957a6d6c29f993ed9239432fef3d2439983a
+Subproject commit d1604efe375ab0baeb8505477a896572af83805b
diff --git
a/src/java/org/apache/cassandra/index/accord/CheckpointIntervalArrayIndex.java
b/src/java/org/apache/cassandra/index/accord/CheckpointIntervalArrayIndex.java
index 9cf950410d..e478d26982 100644
---
a/src/java/org/apache/cassandra/index/accord/CheckpointIntervalArrayIndex.java
+++
b/src/java/org/apache/cassandra/index/accord/CheckpointIntervalArrayIndex.java
@@ -609,7 +609,7 @@ public class CheckpointIntervalArrayIndex
};
var searcher = new CheckpointIntervalArray<>(accessor,
indexInput, checkpoints.bounds, checkpoints.headers, checkpoints.lists,
checkpoints.maxScanAndCheckpointMatches);
-searcher.forEach(start, end, (i1, i2, i3, i4, index) -> {
+searcher.forEachRange(start, end, (i1, i2, i3, i4, index) -> {
stats.matches++;
callback.accept(reader.copyTo(accessor.get(indexInput,
index), buffer));
}, (i1, i2, i3, i4, startIdx, endIdx) -> {
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/04: update accord
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch burn-test-stability
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 02db1057ba995f03ebbe825a81fe679299cd732a
Author: Benedict Elliott Smith
AuthorDate: Fri Aug 2 14:17:42 2024 +0100
update accord
---
.gitmodules | 2 +-
modules/accord | 2 +-
.../apache/cassandra/service/accord/repair/RepairSyncPointAdapter.java | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/.gitmodules b/.gitmodules
index b8fde5f01d..fc9b7c0807 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,4 +1,4 @@
[submodule "modules/accord"]
path = modules/accord
url = https://github.com/belliottsmith/cassandra-accord.git
- branch = cfk-pruning
+ branch = exclusive-sync-point-fix
diff --git a/modules/accord b/modules/accord
index 1a74008be3..1c8b89da1f 16
--- a/modules/accord
+++ b/modules/accord
@@ -1 +1 @@
-Subproject commit 1a74008be31f818b89aec2ed67490fba5dc12175
+Subproject commit 1c8b89da1fe6afd4f8691b8fe8328091055dedc2
diff --git
a/src/java/org/apache/cassandra/service/accord/repair/RepairSyncPointAdapter.java
b/src/java/org/apache/cassandra/service/accord/repair/RepairSyncPointAdapter.java
index 76e29adbc5..8cc04f60da 100644
---
a/src/java/org/apache/cassandra/service/accord/repair/RepairSyncPointAdapter.java
+++
b/src/java/org/apache/cassandra/service/accord/repair/RepairSyncPointAdapter.java
@@ -61,7 +61,7 @@ public class RepairSyncPointAdapter> extends Coordinat
public void execute(Node node, Topologies all, FullRoute route,
ExecutePath path, TxnId txnId, Txn txn, Timestamp executeAt, Deps deps,
BiConsumer, Throwable> callback)
{
RequiredResponseTracker tracker = new
RequiredResponseTracker(requiredResponses, all);
-ExecuteSyncPoint.ExecuteBlocking execute = new
ExecuteSyncPoint.ExecuteBlocking<>(node, tracker, new SyncPoint<>(txnId, deps,
(S) txn.keys(), route), executeAt);
+ExecuteSyncPoint.ExecuteBlocking execute = new
ExecuteSyncPoint.ExecuteBlocking<>(node, new SyncPoint<>(txnId, deps, (S)
txn.keys(), route), tracker, executeAt);
execute.addCallback(callback);
execute.start();
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 03/04: fix some compilation issues
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch burn-test-stability
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 12ba2c2eb3bdc6ffd23994ffc94be5e5971af44b
Author: Benedict Elliott Smith
AuthorDate: Fri Aug 2 22:45:12 2024 +0100
fix some compilation issues
---
modules/accord | 2 +-
.../cassandra/db/compaction/CompactionIterator.java | 15 +--
.../cassandra/service/accord/AccordService.java | 11 +++
.../cassandra/service/accord/AccordTopology.java | 15 +--
.../cassandra/service/accord/IAccordService.java | 18 --
.../service/accord/fastpath/FastPathStrategy.java| 4 +++-
.../fastpath/InheritKeyspaceFastPathStrategy.java| 4 +++-
.../fastpath/ParameterizedFastPathStrategy.java | 11 ++-
.../accord/fastpath/SimpleFastPathStrategy.java | 20
.../db/compaction/CompactionAccordIteratorsTest.java | 4 ++--
.../cassandra/service/accord/AccordTestUtils.java| 7 +--
.../fastpath/ParameterizedFastPathStrategyTest.java | 4 +++-
12 files changed, 76 insertions(+), 39 deletions(-)
diff --git a/modules/accord b/modules/accord
index ce6e7a514d..5e80957a6d 16
--- a/modules/accord
+++ b/modules/accord
@@ -1 +1 @@
-Subproject commit ce6e7a514de1d4b6ad1c290df423b831664fd535
+Subproject commit 5e80957a6d6c29f993ed9239432fef3d2439983a
diff --git
a/src/java/org/apache/cassandra/db/compaction/CompactionIterator.java
b/src/java/org/apache/cassandra/db/compaction/CompactionIterator.java
index e0dcb5682f..6e56bd8441 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionIterator.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionIterator.java
@@ -32,6 +32,7 @@ import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Ordering;
import accord.local.Cleanup;
+import accord.local.CommandStores.RangesForEpoch;
import accord.local.DurableBefore;
import accord.local.RedundantBefore;
import accord.local.SaveStatus;
@@ -784,6 +785,7 @@ public class CompactionIterator extends
CompactionInfo.Holder implements Unfilte
class AccordCommandsPurger extends AbstractPurger
{
final Int2ObjectHashMap redundantBefores;
+final Int2ObjectHashMap ranges;
final DurableBefore durableBefore;
int storeId;
@@ -791,9 +793,10 @@ public class CompactionIterator extends
CompactionInfo.Holder implements Unfilte
AccordCommandsPurger(Supplier accordService)
{
-Pair, DurableBefore>
redundantBeforesAndDurableBefore =
accordService.get().getRedundantBeforesAndDurableBefore();
-this.redundantBefores = redundantBeforesAndDurableBefore.left;
-this.durableBefore = redundantBeforesAndDurableBefore.right;
+IAccordService.CompactionInfo compactionInfo =
accordService.get().getCompactionInfo();
+this.redundantBefores = compactionInfo.redundantBefores;
+this.ranges = compactionInfo.ranges;
+this.durableBefore = compactionInfo.durableBefore;
}
protected void beginPartition(UnfilteredRowIterator partition)
@@ -815,7 +818,7 @@ public class CompactionIterator extends
CompactionInfo.Holder implements Unfilte
// When commands end up being sliced by compaction we need this to
discard tombstones and slices
// without enough information to run the rest of the cleanup logic
-if (Cleanup.isSafeToCleanup(durableBefore, txnId))
+if (Cleanup.isSafeToCleanup(durableBefore, txnId,
ranges.get(storeId).allAt(txnId.epoch(
return null;
Cell durabilityCell = row.getCell(CommandsColumns.durability);
@@ -878,7 +881,7 @@ public class CompactionIterator extends
CompactionInfo.Holder implements Unfilte
AccordTimestampsForKeyPurger(Supplier accordService)
{
-this.redundantBefores =
accordService.get().getRedundantBeforesAndDurableBefore().left;
+this.redundantBefores =
accordService.get().getCompactionInfo().redundantBefores;
}
protected void beginPartition(UnfilteredRowIterator partition)
@@ -954,7 +957,7 @@ public class CompactionIterator extends
CompactionInfo.Holder implements Unfilte
AccordCommandsForKeyPurger(CommandsForKeyAccessor accessor,
Supplier accordService)
{
this.accessor = accessor;
-this.redundantBefores =
accordService.get().getRedundantBeforesAndDurableBefore().left;
+this.redundantBefores =
accordService.get().getCompactionInfo().redundantBefores;
}
protected void beginPartition(UnfilteredRowIterator partition)
diff --git a/src/java/org/apache/cassandra/service/accord/AccordService.java
b/src/java/org/apache/cassandra/service/accord/AccordService.java
index
(cassandra) branch burn-test-stability created (now 97c1296697)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch burn-test-stability in repository https://gitbox.apache.org/repos/asf/cassandra.git at 97c1296697 fix compilation This branch includes the following new commits: new 02db1057ba update accord new 64451dde91 burn test stability: wip new 12ba2c2eb3 fix some compilation issues new 97c1296697 fix compilation The 4 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870626#comment-17870626
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/2/24 9:03 PM:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
This PR should also address
https://issues.apache.org/jira/browse/CASSANDRA-11695
was (Author: maulin.vasavada):
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Anthony Grasso
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870626#comment-17870626
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/2/24 9:01 PM:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
was (Author: maulin.vasavada):
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could over the spacing issues :) I did run `ant
check` locally so hoping for the best. I added more unit tests for JMX SSL
verification (for existing and the PR changes) but didn't find any tests I can
use to really validate Remote JMX SSL config working at runtime by creating
server-socket etc. Open to suggestions on how to add that kind of test.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Anthony Grasso
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
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-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870626#comment-17870626
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could over the spacing issues :) I did run `ant
check` locally so hoping for the best. I added more unit tests for JMX SSL
verification (for existing and the PR changes) but didn't find any tests I can
use to really validate Remote JMX SSL config working at runtime by creating
server-socket etc. Open to suggestions on how to add that kind of test.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Anthony Grasso
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
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-19810) Add snapshot repo aliasing to build.properties.default and build-resolver.xml
[
https://issues.apache.org/jira/browse/CASSANDRA-19810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870622#comment-17870622
]
Michael Semb Wever commented on CASSANDRA-19810:
bq. What's the mechanism to check for and validate this?
Beyond not permitting snapshot repositories, it's manual.
> Add snapshot repo aliasing to build.properties.default and build-resolver.xml
> -
>
> Key: CASSANDRA-19810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19810
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Attachments: fix_snapshot_repo.diff
>
>
> Currently {{resolver-apache-snapshot}} is hard-coded in
> {{build-resolver.xml}} and overriding it isn't supported in
> {{build.properties.default}}. Further, the comment on that repository in
> {{build-resolver.xml}} is... rather confusing, since it states we don't
> support it and to uncomment it out if you need it, but then it's already
> uncommented out.
> We should just support aliasing the snapshot repo the way we do the others.
--
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-19810) Add snapshot repo aliasing to build.properties.default and build-resolver.xml
[
https://issues.apache.org/jira/browse/CASSANDRA-19810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870612#comment-17870612
]
Josh McKenzie commented on CASSANDRA-19810:
---
bq. We can't include dependencies that themselves have unpinned dependencies.
What's the mechanism to check for and validate this? There's definitely records
in {{parent-pom-template.xml}} that allude to this state.
> Add snapshot repo aliasing to build.properties.default and build-resolver.xml
> -
>
> Key: CASSANDRA-19810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19810
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Attachments: fix_snapshot_repo.diff
>
>
> Currently {{resolver-apache-snapshot}} is hard-coded in
> {{build-resolver.xml}} and overriding it isn't supported in
> {{build.properties.default}}. Further, the comment on that repository in
> {{build-resolver.xml}} is... rather confusing, since it states we don't
> support it and to uncomment it out if you need it, but then it's already
> uncommented out.
> We should just support aliasing the snapshot repo the way we do the others.
--
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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-19321: -- Reviewers: David Capwell, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > Labels: pull-request-available > Attachments: ci_summary.html.zip > > Time Spent: 2h 10m > Remaining Estimate: 0h > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- 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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-19321: --- Labels: pull-request-available (was: ) > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > Labels: pull-request-available > Attachments: ci_summary.html.zip > > Time Spent: 1h 50m > Remaining Estimate: 0h > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- 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] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
michaelsembwever commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1702151894 ## NOTICE: ## @@ -48,7 +48,7 @@ Matt Robenolt Phillip Couto * Niklas Korz Nimi Wariboko Jr -Ghais Issa +Ghais Issa * Review Comment: done, in https://github.com/apache/cassandra-gocql-driver/pull/1792 -- 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
[PR] Update new contribution agreement from Ghais Issa [cassandra-gocql-driver]
michaelsembwever opened a new pull request, #1792: URL: https://github.com/apache/cassandra-gocql-driver/pull/1792 patch by Mick Semb Wever; reviewed by XXX for CASSANDRA-19723 -- 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
Re: [PR] Update CONTRIBUTING for project's new home [cassandra-gocql-driver]
michaelsembwever commented on code in PR #1787: URL: https://github.com/apache/cassandra-gocql-driver/pull/1787#discussion_r1702123651 ## CONTRIBUTING.md: ## @@ -6,21 +6,22 @@ This guide outlines the process of landing patches in gocql and the general appr ## Background -The goal of the gocql project is to provide a stable and robust CQL driver for Go. gocql is a community driven project that is coordinated by a small team of core developers. +The goal of the gocql project is to provide a stable and robust CQL driver for Go. This is a community driven project that is coordinated by a small team of developers in and around the Apache Cassandra project. For security, governance and administration issues please refer to the Cassandra Project Management Committee. ## Minimum Requirement Checklist The following is a check list of requirements that need to be satisfied in order for us to merge your patch: -* You should raise a pull request to gocql/gocql on Github +* You should raise a pull request to apache/cassandra-gocql-driver on Github * The pull request has a title that clearly summarizes the purpose of the patch * The motivation behind the patch is clearly defined in the pull request summary -* Your name and email have been added to the `AUTHORS` file (for copyright purposes) +* You agree that your contribution is donated to the Apache Software Foundation (appropriate copyright is on all new files) * The patch will merge cleanly * The test coverage does not fall below the critical threshold (currently 64%) * The merge commit passes the regression test suite on Travis * `go fmt` has been applied to the submitted code * Notable changes (i.e. new features or changed behavior, bugfixes) are appropriately documented in CHANGELOG.md, functional changes also in godoc +* A correctly formatted commit message, see https://cassandra.apache.org/_/development/how_to_commit.html#tips Review Comment: > Should we encourage contributors to use signed git commits? This isn't project precedence, though it can always be recommended (and should be). Ultimately, it's not my call. -- 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-19631) Consider autocompletion of in-built functions in CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-19631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhanush Ananthkar updated CASSANDRA-19631: -- Test and Documentation Plan: ran pytests and pycodestyle Status: Patch Available (was: In Progress) > Consider autocompletion of in-built functions in CQLSH > -- > > Key: CASSANDRA-19631 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Dhanush Ananthkar >Priority: Normal > > Why do we not autocomplete native functions in CQLSH shell? I am pretty lost > in what functions are there to choose from without consulting the > documentation. > Additionally, the documentation on [Blob conversion > functions|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#blob-conversion-functions] > could use an example, as done for the other builtins. -- 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-19321) Accord: Command to mark replicas as “stale" for decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19321: Reviewers: Sam Tunnicliffe > Accord: Command to mark replicas as “stale" for decommission > > > Key: CASSANDRA-19321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19321 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Caleb Rackliffe >Priority: High > Attachments: ci_summary.html.zip > > Time Spent: 1h 40m > Remaining Estimate: 0h > > So that other replicas may continue to cleanup their state, we must have an > operator command for marking replicas as stale so that the remaining replicas > do not wait for them to coordinate their durability status. -- 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-19321) Accord: Command to mark replicas as “stale" for decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870580#comment-17870580
]
Caleb Rackliffe commented on CASSANDRA-19321:
-
Notes on test failures in the initial run:
1.) Simulator and Harry tests are either failing upstream or fixed upstream.
2.) The following tests are also failing in {{cep-15-accord}}, so likely not
caused by this patch:
{{AccordIncrementalRepairTest}}
{{RepairDigestTrackingTest}}
{{ShortReadProtectionTest}}
3.) The following tests don't fail locally in either my branch or
{{cep-15-accord}}, and may be CI env-related:
{{SafeMemoryWriterTest}}
{{HintedHandoffAddRemoveNodesTest}}
{{FullAccordCQLTest}}
{{CommitLogSegmentManagerCDCTest}}
{{JournalTest}}
4.) Python dtest failures look like mostly an artifact of {{cep-15-accord}}
being behind {{trunk}}.
> Accord: Command to mark replicas as “stale" for decommission
>
>
> Key: CASSANDRA-19321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19321
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Caleb Rackliffe
>Priority: High
> Attachments: ci_summary.html.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> So that other replicas may continue to cleanup their state, we must have an
> operator command for marking replicas as stale so that the remaining replicas
> do not wait for them to coordinate their durability status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870469#comment-17870469 ] Brandon Williams commented on CASSANDRA-19448: -- No problem, next time I'll just multiplex that test to help speed things along. > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Description: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] was: The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split almost always now. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now. > Our 5.0-rc testing results are tainted because these time outs always abort > the 5.0 pipeline runs. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Fix Version/s: 5.0-rc > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split almost always now. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19813: --- Bug Category: Parent values: Degradation(12984)Level 1 values: Slow Use Case(12996) Complexity: Challenging Discovered By: DTest Severity: Critical Status: Open (was: Triage Needed) > timeout on > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > - > > Key: CASSANDRA-19813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > Attachments: test_rolling_upgrade.122.log, > test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, > test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log > > > The > upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade > test is taking longer than usual. > CI in 5.0 is timing out the dtest-upgrade-large 59/64 split almost always now. > It looks like that split is taking 16x times as long now… > This appears to be caused from either/both > - > https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 > - > https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa > Example of good run. > [^test_rolling_upgrade.257.good.log] > Examples of bad runs. > [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], > [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] -- 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-19813) timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
Michael Semb Wever created CASSANDRA-19813: -- Summary: timeout on upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade Key: CASSANDRA-19813 URL: https://issues.apache.org/jira/browse/CASSANDRA-19813 Project: Cassandra Issue Type: Bug Components: CI Reporter: Michael Semb Wever Attachments: test_rolling_upgrade.122.log, test_rolling_upgrade.123-1.log, test_rolling_upgrade.123-2.log, test_rolling_upgrade.134.log, test_rolling_upgrade.257.good.log The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade test is taking longer than usual. CI in 5.0 is timing out the dtest-upgrade-large 59/64 split almost always now. It looks like that split is taking 16x times as long now… This appears to be caused from either/both - https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588 - https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa Example of good run. [^test_rolling_upgrade.257.good.log] Examples of bad runs. [^test_rolling_upgrade.122.log], [^test_rolling_upgrade.123-2.log], [^test_rolling_upgrade.123-1.log], [^test_rolling_upgrade.134.log] -- 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-19779) direct IO support is always evaluated to false upon the very first start of a node
[
https://issues.apache.org/jira/browse/CASSANDRA-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19779:
--
Reviewers: Branimir Lambov, Maxwell Guo
Status: Review In Progress (was: Needs Committer)
> direct IO support is always evaluated to false upon the very first start of a
> node
> --
>
> Key: CASSANDRA-19779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19779
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When I extract the distribution tarball and I want to use tools in tools/bin,
> there is this warn log visible every time for tools when they are started
> (does not happen on "help" command, obviously)
> {code:java}
> WARN 14:25:11,835 Unable to determine block size for commit log directory:
> null {code}
> This is because we introduced this (1) in CASSANDRA-18464
> What that does is that it will go and try to create a temporary file in
> commit log directory to get "block size" for a "file store" that file is in.
> The problem with that is that when we just extract a tarball and run the
> tools - Cassandra was never started - then such commit log directory does not
> exist yet, so it tries to create a temporary file in a non-existing
> directory, which fails, hence the log message.
> The fix is to check if commitlog dir exists and return / skip the resolution
> of block size if it does not.
> Another approach might be to check if this is executed in the context of a
> tool and skip it from resolution altogether. The problem with this is that
> not all tools we have in bin/log call DatabaseDescriptor.
> toolInitialization() so we might combine these two.
> (1)
> [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1455-L1462]
--
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-19779) direct IO support is always evaluated to false upon the very first start of a node
[
https://issues.apache.org/jira/browse/CASSANDRA-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19779:
--
Status: Ready to Commit (was: Review In Progress)
[~blambov] approved on the PR
> direct IO support is always evaluated to false upon the very first start of a
> node
> --
>
> Key: CASSANDRA-19779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19779
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0-rc
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When I extract the distribution tarball and I want to use tools in tools/bin,
> there is this warn log visible every time for tools when they are started
> (does not happen on "help" command, obviously)
> {code:java}
> WARN 14:25:11,835 Unable to determine block size for commit log directory:
> null {code}
> This is because we introduced this (1) in CASSANDRA-18464
> What that does is that it will go and try to create a temporary file in
> commit log directory to get "block size" for a "file store" that file is in.
> The problem with that is that when we just extract a tarball and run the
> tools - Cassandra was never started - then such commit log directory does not
> exist yet, so it tries to create a temporary file in a non-existing
> directory, which fails, hence the log message.
> The fix is to check if commitlog dir exists and return / skip the resolution
> of block size if it does not.
> Another approach might be to check if this is executed in the context of a
> tool and skip it from resolution altogether. The problem with this is that
> not all tools we have in bin/log call DatabaseDescriptor.
> toolInitialization() so we might combine these two.
> (1)
> [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1455-L1462]
--
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-19803) Flakey test org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
[
https://issues.apache.org/jira/browse/CASSANDRA-19803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19803:
Status: Ready to Commit (was: Review In Progress)
+1
> Flakey test
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
> -
>
> Key: CASSANDRA-19803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19803
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: SHOULD NOT BE ON NODE: 11 --
> [(16,30)]: [00, 02, 04, 06, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 42, 44, 46, 48]
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:231)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test.testMoveForward(TransientRangeMovement2Test.java:143)
> {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-19803) Flakey test org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
[
https://issues.apache.org/jira/browse/CASSANDRA-19803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19803:
Reviewers: Sam Tunnicliffe, Sam Tunnicliffe
Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
Status: Review In Progress (was: Patch Available)
> Flakey test
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
> -
>
> Key: CASSANDRA-19803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19803
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: SHOULD NOT BE ON NODE: 11 --
> [(16,30)]: [00, 02, 04, 06, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 42, 44, 46, 48]
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:231)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test.testMoveForward(TransientRangeMovement2Test.java:143)
> {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] [Commented] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time
[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870412#comment-17870412 ] Maxwell Guo commented on CASSANDRA-19448: - [~brandon.williams]Sorry for that. As my ci 's resource is limited, so I just run the ut test case locally with a repeat number of 20 in a for loop. The locally test were always successful, So I push the code . I will run them again. > CommitlogArchiver only has granularity to seconds for restore_point_in_time > --- > > Key: CASSANDRA-19448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19448 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jeremy Hanna >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Commitlog archiver allows users to backup commitlog files for the purpose of > doing point in time restores. The [configuration > file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] > gives an example of down to the seconds granularity but then asks what > whether the timestamps are microseconds or milliseconds - defaulting to > microseconds. Because the [CommitLogArchiver uses a second based date > format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], > if a user specifies to restore at something at a lower granularity like > milliseconds or microseconds, that means that the it will truncate everything > after the second and restore to that second. So say you specify a > restore_point_in_time like this: > restore_point_in_time=2024:01:18 17:01:01.623392 > it will silently truncate everything after the 01 seconds. So effectively to > the user, it is missing updates between 01 and 01.623392. > This appears to be a bug in the intent. We should allow users to specify > down to the millisecond or even microsecond level. If we allow them to > specify down to microseconds for the restore point in time, then it may > internally need to change from a long. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19804) Flakey test upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD#test_rolling_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-19804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19804:
Fix Version/s: 5.1-alpha1
(was: 5.x)
Since Version: 5.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/9fb141ffcc26108f04a4faf6848ad6080ca4d481
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
committed, thanks!
> Flakey test
> upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD#test_rolling_upgrade
> -
>
> Key: CASSANDRA-19804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19804
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code}
> ERRORS
>
> _ ERROR at teardown of
> TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD.test_rolling_upgrade _
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node3] 'ERROR [InternalResponseStage:3] 2024-07-26 04:35:12,345
> MessagingService.java:509 - Cannot send the message (from:/127.0.0.3:7000,
> type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to /127.0.0.1:7000, as messaging
> service is shutting down', [node3] 'ERROR [InternalResponseStage:4]
> 2024-07-26 04:35:27,412 MessagingService.java:509 - Cannot send the message
> (from:/127.0.0.3:7000, type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to
> /127.0.0.1:7000, as messaging service is shutting down']
> {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
(cassandra) branch trunk updated: Change log level when sending message during messaging service shutdown.
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9fb141ffcc Change log level when sending message during messaging
service shutdown.
9fb141ffcc is described below
commit 9fb141ffcc26108f04a4faf6848ad6080ca4d481
Author: Marcus Eriksson
AuthorDate: Mon Jul 29 11:21:17 2024 +0200
Change log level when sending message during messaging service shutdown.
Patch by marcuse; reviewed by Sam Tunnicliffe for CASSANDRA-19804
---
src/java/org/apache/cassandra/net/MessagingService.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index 47c4830d20..f26d35ad95 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -506,7 +506,7 @@ public class MessagingService extends
MessagingServiceMBeanImpl implements Messa
{
if (isShuttingDown)
{
-logger.error("Cannot send the message {} to {}, as messaging
service is shutting down", message, to);
+logger.warn("Cannot send the message {} to {}, as messaging
service is shutting down", message, to);
return;
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19803) Flakey test org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
[
https://issues.apache.org/jira/browse/CASSANDRA-19803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19803:
Test and Documentation Plan: ci run
Status: Patch Available (was: Open)
we don't wait for move to finish before running cleanup
> Flakey test
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
> -
>
> Key: CASSANDRA-19803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19803
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: SHOULD NOT BE ON NODE: 11 --
> [(16,30)]: [00, 02, 04, 06, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 42, 44, 46, 48]
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:231)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test.testMoveForward(TransientRangeMovement2Test.java:143)
> {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-19803) Flakey test org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
[
https://issues.apache.org/jira/browse/CASSANDRA-19803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19803:
Attachment: ci_summary.html
> Flakey test
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
> -
>
> Key: CASSANDRA-19803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19803
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: SHOULD NOT BE ON NODE: 11 --
> [(16,30)]: [00, 02, 04, 06, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
> 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 42, 44, 46, 48]
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:231)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovement2Test.testMoveForward(TransientRangeMovement2Test.java:143)
> {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-19812) We should throw exception when commitlog 's DiskAccessMode is direct but direct io is not support
[
https://issues.apache.org/jira/browse/CASSANDRA-19812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-19812:
Change Category: Operability
Fix Version/s: 5.x
Status: Open (was: Triage Needed)
> We should throw exception when commitlog 's DiskAccessMode is direct but
> direct io is not support
> -
>
> Key: CASSANDRA-19812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19812
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Commit Log
>Reporter: Maxwell Guo
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Looking into the code below :
> {code:java}
> private static DiskAccessMode
> resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
> {
> boolean compressOrEncrypt = getCommitLogCompression() != null ||
> (getEncryptionContext() != null && getEncryptionContext().isEnabled());
> boolean directIOSupported = false;
> try
> {
> directIOSupported = FileUtils.getBlockSize(new
> File(getCommitLogLocation())) > 0;
> }
> catch (RuntimeException e)
> {
> logger.warn("Unable to determine block size for commit log
> directory: {}", e.getMessage());
> }
> if (providedDiskAccessMode == DiskAccessMode.auto)
> {
> if (compressOrEncrypt)
> providedDiskAccessMode = DiskAccessMode.legacy;
> else
> {
> providedDiskAccessMode = directIOSupported &&
> conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ?
> DiskAccessMode.direct
>
>:
> DiskAccessMode.legacy;
> }
> }
> if (providedDiskAccessMode == DiskAccessMode.legacy)
> {
> providedDiskAccessMode = compressOrEncrypt ?
> DiskAccessMode.standard : DiskAccessMode.mmap;
> }
> return providedDiskAccessMode;
> }
> {code}
> We should throw exception when user set the DiskAccessMode to direct for
> commitlog but the directIOSupported return false after the judgement of
> "FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of
> waiting for the system to start and accepting reads and writes.
--
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-19812) We should throw exception when commitlog 's DiskAccessMode is direct but direct io is not support
[
https://issues.apache.org/jira/browse/CASSANDRA-19812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-19812:
Complexity: Low Hanging Fruit
Component/s: Local/Commit Log
> We should throw exception when commitlog 's DiskAccessMode is direct but
> direct io is not support
> -
>
> Key: CASSANDRA-19812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19812
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Commit Log
>Reporter: Maxwell Guo
>Assignee: Maxwell Guo
>Priority: Normal
>
> Looking into the code below :
> {code:java}
> private static DiskAccessMode
> resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
> {
> boolean compressOrEncrypt = getCommitLogCompression() != null ||
> (getEncryptionContext() != null && getEncryptionContext().isEnabled());
> boolean directIOSupported = false;
> try
> {
> directIOSupported = FileUtils.getBlockSize(new
> File(getCommitLogLocation())) > 0;
> }
> catch (RuntimeException e)
> {
> logger.warn("Unable to determine block size for commit log
> directory: {}", e.getMessage());
> }
> if (providedDiskAccessMode == DiskAccessMode.auto)
> {
> if (compressOrEncrypt)
> providedDiskAccessMode = DiskAccessMode.legacy;
> else
> {
> providedDiskAccessMode = directIOSupported &&
> conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ?
> DiskAccessMode.direct
>
>:
> DiskAccessMode.legacy;
> }
> }
> if (providedDiskAccessMode == DiskAccessMode.legacy)
> {
> providedDiskAccessMode = compressOrEncrypt ?
> DiskAccessMode.standard : DiskAccessMode.mmap;
> }
> return providedDiskAccessMode;
> }
> {code}
> We should throw exception when user set the DiskAccessMode to direct for
> commitlog but the directIOSupported return false after the judgement of
> "FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of
> waiting for the system to start and accepting reads and writes.
--
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-19812) We should throw exception when commitlog 's DiskAccessMode is direct but direct io is not support
[
https://issues.apache.org/jira/browse/CASSANDRA-19812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo reassigned CASSANDRA-19812:
---
Assignee: Maxwell Guo
> We should throw exception when commitlog 's DiskAccessMode is direct but
> direct io is not support
> -
>
> Key: CASSANDRA-19812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19812
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maxwell Guo
>Assignee: Maxwell Guo
>Priority: Normal
>
> Looking into the code below :
> {code:java}
> private static DiskAccessMode
> resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
> {
> boolean compressOrEncrypt = getCommitLogCompression() != null ||
> (getEncryptionContext() != null && getEncryptionContext().isEnabled());
> boolean directIOSupported = false;
> try
> {
> directIOSupported = FileUtils.getBlockSize(new
> File(getCommitLogLocation())) > 0;
> }
> catch (RuntimeException e)
> {
> logger.warn("Unable to determine block size for commit log
> directory: {}", e.getMessage());
> }
> if (providedDiskAccessMode == DiskAccessMode.auto)
> {
> if (compressOrEncrypt)
> providedDiskAccessMode = DiskAccessMode.legacy;
> else
> {
> providedDiskAccessMode = directIOSupported &&
> conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ?
> DiskAccessMode.direct
>
>:
> DiskAccessMode.legacy;
> }
> }
> if (providedDiskAccessMode == DiskAccessMode.legacy)
> {
> providedDiskAccessMode = compressOrEncrypt ?
> DiskAccessMode.standard : DiskAccessMode.mmap;
> }
> return providedDiskAccessMode;
> }
> {code}
> We should throw exception when user set the DiskAccessMode to direct for
> commitlog but the directIOSupported return false after the judgement of
> "FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of
> waiting for the system to start and accepting reads and writes.
--
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-19812) We should throw exception when commitlog 's DiskAccessMode is direct but direct io is not support
Maxwell Guo created CASSANDRA-19812:
---
Summary: We should throw exception when commitlog 's
DiskAccessMode is direct but direct io is not support
Key: CASSANDRA-19812
URL: https://issues.apache.org/jira/browse/CASSANDRA-19812
Project: Cassandra
Issue Type: Improvement
Reporter: Maxwell Guo
Looking into the code below :
{code:java}
private static DiskAccessMode
resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
{
boolean compressOrEncrypt = getCommitLogCompression() != null ||
(getEncryptionContext() != null && getEncryptionContext().isEnabled());
boolean directIOSupported = false;
try
{
directIOSupported = FileUtils.getBlockSize(new
File(getCommitLogLocation())) > 0;
}
catch (RuntimeException e)
{
logger.warn("Unable to determine block size for commit log
directory: {}", e.getMessage());
}
if (providedDiskAccessMode == DiskAccessMode.auto)
{
if (compressOrEncrypt)
providedDiskAccessMode = DiskAccessMode.legacy;
else
{
providedDiskAccessMode = directIOSupported &&
conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ?
DiskAccessMode.direct
: DiskAccessMode.legacy;
}
}
if (providedDiskAccessMode == DiskAccessMode.legacy)
{
providedDiskAccessMode = compressOrEncrypt ?
DiskAccessMode.standard : DiskAccessMode.mmap;
}
return providedDiskAccessMode;
}
{code}
We should throw exception when user set the DiskAccessMode to direct for
commitlog but the directIOSupported return false after the judgement of
"FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of
waiting for the system to start and accepting reads and writes.
--
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
