[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524704#comment-17524704 ] Dinesh Joshi commented on CASSANDRA-17513: -- Hi [~maulin.vasavada] I've updated the title to reflect more clearly as per your recommendation. My preference is to stick to explicit vs implicit. This makes things very clear for operators. There are no magical assumptions hidden in the code. So, currently we have connection settings for native protocol and internode communication. The native protocol further splits the settings into server and client settings. I believe we should keep the same pattern as it maintains consistency in the configuration. We could certainly use the same server/client truststore/keystore across both native and internode configuration. Nothing preventing us from doing that. So, at best the operator deals with one truststore and one keystore across both settings blocks. This is no worse than today. Now, if the operator can choose to generate a unique truststore and keystore for native and internode configuration. In this situation its by choice and nothing in Cassandra should force them to do this. On the extendedKeyUsage, one big downside is that the server and client certificates are stored in the same file on disk. Client certificates can expire rather quickly and this will translate into more frequent updates to the server certificates due to hot reloading. We will need to add additional logic to the hot reloading code path to ensure we do not reload the server certificate when the client certificate changes. This is undesirable behavior IMHO. A number of systems may not support packing server and client certificates into the same store file. We may actually cause additional burden in that situation by requiring operators to write scripts to package both server and client certificates in the same store file. This is unnecessary. I am open to considering implementing this idea if we don't force operators to explicitly a single store file i.e. maintain backward compatibility with what we have. However, it feels like this should be out of scope here and we can create a separate ticket to address it across both native and internode configurations. WDYT? > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17513: - Summary: Adding support for TLS client authentication for internode communication (was: Add new property to pass keystore for outbound connections) > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524671#comment-17524671 ] Erick Ramirez commented on CASSANDRA-17555: --- I didn't get around to reviewing this last week before I went on Easter holidays so I'll need to modify the date. [~Calico], when do you want it published? > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17555: -- Source Control Link: (was: https://github.com/apache/cassandra-website/pull/124/commits/8216b1f92c9781fe4949b090249ede992d5e2e85) > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17555: -- Authors: Chris Thornett, Diogenese Topper (was: Erick Ramirez) > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17555) WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr Sorokoumov"
[ https://issues.apache.org/jira/browse/CASSANDRA-17555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17555: - Assignee: Erick Ramirez > WEBSITE - April 2022 blog "Inside Cassandra: An Interview with Project > Contributor, Aleksandr Sorokoumov" > - > > Key: CASSANDRA-17555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17555 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Inside Cassandra: An Interview with Project Contributor, Aleksandr > Sorokoumov" > If this blog cannot be published by the *April 14, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524656#comment-17524656 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - Pushed to trunk 4000 times too as it failed 5 times with my patch https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127 > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17564) Add synchronization to wait for outstanding tasks in the compaction executor and nonPeriodicTasks during CassandraDaemon setup
[
https://issues.apache.org/jira/browse/CASSANDRA-17564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haoze Wu updated CASSANDRA-17564:
-
Description:
We have been testing Cassandra 3.11.10 for a while. During a node start, we
found that a synchronization guarantee implied by the code comments is not
enforced. Specifically, in the `invalidate` method called in this call stack
(in version 3.11.10):
{code:java}
org.apache.cassandra.service.CassandraDaemon#main:786
org.apache.cassandra.service.CassandraDaemon#activate:633
org.apache.cassandra.service.CassandraDaemon#setup:261
org.apache.cassandra.schema.LegacySchemaMigrator#migrate:83
org.apache.cassandra.schema.LegacySchemaMigrator#unloadLegacySchemaTables:137
java.lang.Iterable#forEach:75
org.apache.cassandra.schema.LegacySchemaMigrator#lambda$unloadLegacySchemaTables$1:137
org.apache.cassandra.db.ColumnFamilyStore#invalidate:542 {code}
In line 564~570 within `public void invalidate(boolean expectMBean)`:
{code:java}
latencyCalculator.cancel(false);
compactionStrategyManager.shutdown();
SystemKeyspace.removeTruncationRecord(metadata.cfId); // line 566
data.dropSSTables(); // line 568
LifecycleTransaction.waitForDeletions(); // line 569
indexManager.invalidateAllIndexesBlocking();
{code}
According to the code and the comments, we suppose `data.dropSSTables()` in
line 568 will submit some tidier tasks to the `nonPeriodicTasks` thread pool.
Call stack in version 3.11.10:
{code:java}
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:233
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:238
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:267
org.apache.cassandra.utils.concurrent.Refs#release:241
org.apache.cassandra.utils.concurrent.Ref#release:119
org.apache.cassandra.utils.concurrent.Ref#release:225
org.apache.cassandra.utils.concurrent.Ref#release:326
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier#tidy:2205
{code}
Then, `LifecycleTransaction.waitForDeletions()` in line 569 is
{code:java}
/**
* Deletions run on the nonPeriodicTasks executor, (both failedDeletions or
global tidiers in SSTableReader)
* so by scheduling a new empty task and waiting for it we ensure any prior
deletion has completed.
*/
public static void waitForDeletions()
{
LogTransaction.waitForDeletions();
}
{code}
And then call `waitForDeletions` in `LogTransaction`:
{code:java}
static void waitForDeletions()
{
FBUtilities.waitOnFuture(ScheduledExecutors.nonPeriodicTasks.schedule(Runnables.doNothing(),
0, TimeUnit.MILLISECONDS));
}
{code}
>From the comments, we think it ensures that all existing tasks in
>`nonPeriodicTasks` are drained. However, we found some tidier tasks are still
>running in `nonPeriodicTasks` thread pool.
We suspect that those tidier tasks should be guaranteed to finish during server
setup, because of its exception handling. In version 3.11.10, these tidier
tasks are submitted to `nonPeriodicTasks` in
`SSTableReader$InstanceTidier#tidy:2205`, and have the exception handling
`FileUtils.handleFSErrorAndPropagate(new FSWriteError(e, file))` (within the
call stack `SSTableReader$InstanceTidier$1#run:2223` =>
`LogTransaction$SSTableTidier#run:386` => `LogTransaction#delete:261`).
The `FileUtils.handleFSErrorAndPropagate` handles this `FSWriteError`. We found
that it checks the `CassandraDaemon.setupCompleted` flag in call stack within
(`FileUtils#handleFSErrorAndPropagate:507` =>
`JVMStabilityInspector#inspectThrowable:60` =>
`JVMStabilityInspector#inspectThrowable:106` =>
`JVMStabilityInspector#inspectDiskError:73` => `FileUtils#handleFSError:494` =>
`DefaultFSErrorHandler:handleFSError:58`)
{code:java}
if (!StorageService.instance.isDaemonSetupCompleted()) // line 58
handleStartupFSError(e); // line 59
{code}
The `handleStartupFSError` in line 59 will trigger server crash immediately. It
prevents the faulty state early in the startup phase. On the other hand, if the
`CassandraDaemon.setupCompleted` flag is set, we found that the server
tolerates the exception, even in the stop mode in `disk_failure_policy`.
Since those tidier tasks still appear after
`LifecycleTransaction.waitForDeletions()`, we did more experiments to further
confirm that if those tasks got exceptions after the
`CassandraDaemon.setupCompleted` flag is set, the server will suffer from some
internal issues, e.g., fail to handle table read/write. Therefore, we suspect
there could be some concurrency issues — some tidier tasks are not waited.
To figure out the root cause of this concurrency issue, we re-examine line
564~570 within `public void invalidate(boolean expectMBean)` in the
CassandraDaemon main thread:
{code:java}
latencyCalculator.cancel(false);
[jira] [Assigned] (CASSANDRA-17454) flaky dtest-upgrade.upgrade_tests.cql_tests TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17454:
Assignee: Brandon Williams
> flaky dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_indev_4_0_x_To_indev_trunk test_static_cf
> --
>
> Key: CASSANDRA-17454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17454
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Brandon Williams
>Priority: Normal
>
> {code:java}
> Error Messagecassandra.WriteFailure: Error from server: code=1500 [Replica(s)
> failed to execute write] message="Operation failed - received 1 responses and
> 1 failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}Stacktraceself =
> 0x7f36e8ae1a60>
> def test_static_cf(self):
> """ Test static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname text,
> lastname text,
> age int
> );
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins'])
>
> assert_all(cursor, "SELECT * FROM users",
> [[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33, 'Samwise', 'Gamgee'],
>
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32, 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:74:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result() {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17564) Add synchronization to wait for outstanding tasks in the compaction executor and nonPeriodicTasks during CassandraDaemon setup
Haoze Wu created CASSANDRA-17564:
Summary: Add synchronization to wait for outstanding tasks in the
compaction executor and nonPeriodicTasks during CassandraDaemon setup
Key: CASSANDRA-17564
URL: https://issues.apache.org/jira/browse/CASSANDRA-17564
Project: Cassandra
Issue Type: Improvement
Components: Local/Compaction
Reporter: Haoze Wu
We have been testing Cassandra 3.11.10 for a while. During a node start, we
found that a synchronization guarantee implied by the code comments is not
enforced. Specifically, in the `invalidate` method called in this call stack
(in version 3.11.10):
{code:java}
org.apache.cassandra.service.CassandraDaemon#main:786
org.apache.cassandra.service.CassandraDaemon#activate:633
org.apache.cassandra.service.CassandraDaemon#setup:261
org.apache.cassandra.schema.LegacySchemaMigrator#migrate:83
org.apache.cassandra.schema.LegacySchemaMigrator#unloadLegacySchemaTables:137
java.lang.Iterable#forEach:75
org.apache.cassandra.schema.LegacySchemaMigrator#lambda$unloadLegacySchemaTables$1:137
org.apache.cassandra.db.ColumnFamilyStore#invalidate:542 {code}
In line 564~570 within `public void invalidate(boolean expectMBean)`:
{code:java}
latencyCalculator.cancel(false);
compactionStrategyManager.shutdown();
SystemKeyspace.removeTruncationRecord(metadata.cfId); // line 566
data.dropSSTables(); // line 568
LifecycleTransaction.waitForDeletions(); // line 569
indexManager.invalidateAllIndexesBlocking();
{code}
According to the code and the comments, we suppose `data.dropSSTables()` in
line 568 will submit some tidier tasks to the `nonPeriodicTasks` thread pool.
Call stack in version 3.11.10:
{code:java}
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:233
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:238
org.apache.cassandra.db.lifecycle.Tracker#dropSSTables:267
org.apache.cassandra.utils.concurrent.Refs#release:241
org.apache.cassandra.utils.concurrent.Ref#release:119
org.apache.cassandra.utils.concurrent.Ref#release:225
org.apache.cassandra.utils.concurrent.Ref#release:326
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier#tidy:2205
{code}
Then, `LifecycleTransaction.waitForDeletions()` in line 569 is
{code:java}
/**
* Deletions run on the nonPeriodicTasks executor, (both failedDeletions or
global tidiers in SSTableReader)
* so by scheduling a new empty task and waiting for it we ensure any prior
deletion has completed.
*/
public static void waitForDeletions()
{
LogTransaction.waitForDeletions();
}
{code}
And then call `waitForDeletions` in `LogTransaction`:
{code:java}
static void waitForDeletions()
{
FBUtilities.waitOnFuture(ScheduledExecutors.nonPeriodicTasks.schedule(Runnables.doNothing(),
0, TimeUnit.MILLISECONDS));
}
{code}
>From the comments, we think it ensures that all existing tasks in
>`nonPeriodicTasks` are drained. However, we found some tidier tasks are still
>running in `nonPeriodicTasks` thread pool.
We suspect that those tidier tasks should be guaranteed to finish during server
setup, because of its exception handling. In version 3.11.10, these tidier
tasks are submitted to `nonPeriodicTasks` in
`SSTableReader$InstanceTidier#tidy:2205`, and have the exception handling
`FileUtils.handleFSErrorAndPropagate(new FSWriteError(e, file))` (within the
call stack `SSTableReader$InstanceTidier$1#run:2223` =>
`LogTransaction$SSTableTidier#run:386` => `LogTransaction#delete:261`).
The `FileUtils.handleFSErrorAndPropagate` handles this `FSWriteError`. We found
that it checks the `CassandraDaemon.setupCompleted` flag in call stack within
(`FileUtils#handleFSErrorAndPropagate:507` =>
`JVMStabilityInspector#inspectThrowable:60` =>
`JVMStabilityInspector#inspectThrowable:106` =>
`JVMStabilityInspector#inspectDiskError:73` => `FileUtils#handleFSError:494` =>
`DefaultFSErrorHandler:handleFSError:58`)
{code:java}
if (!StorageService.instance.isDaemonSetupCompleted()) // line 58
handleStartupFSError(e); // line 59
{code}
The `handleStartupFSError` in line 59 will trigger server crash immediately. It
prevents the faulty state early in the startup phase. On the other hand, if the
`CassandraDaemon.setupCompleted` flag is set, we found that the server
tolerates the exception, even in the stop mode in `disk_failure_policy`.
Since those tidier tasks still appear after
`LifecycleTransaction.waitForDeletions()`, we did more experiments to further
confirm that if those tasks got exceptions after the
`CassandraDaemon.setupCompleted` flag is set, the server will suffer from some
internal issues, e.g., fail to handle table read/write. Therefore, we suspect
there could be some concurrency issues — some
[cassandra-website] branch asf-staging updated (c4dc66be -> 731de59a)
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 c4dc66be generate docs for b7ad0c5f new 731de59a generate docs for b7ad0c5f 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 (c4dc66be) \ N -- N -- N refs/heads/asf-staging (731de59a) 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 4740078 -> 4740078 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-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524624#comment-17524624 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - Not reproducible... to be on the safe side pushed 4000 times with the patch here - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1562/workflows/847459c5-16aa-43d8-bbdd-92e7165131d0] I will check it back tomorrow morning how it ended up and commit if there are no new surprises > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524622#comment-17524622 ] Ekaterina Dimitrova edited comment on CASSANDRA-17563 at 4/19/22 10:44 PM: --- I identified the issue with trunk but we need to check all branches where the breaking config was committed. CC [~dcapwell] was (Author: e.dimitrova): I identified the issue with trunk but we need to check all branches where the breaking config was committer. CC [~dcapwell] > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524622#comment-17524622 ] Ekaterina Dimitrova commented on CASSANDRA-17563: - I identified the issue with trunk but we need to check all branches where the breaking config was committer. CC [~dcapwell] > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17563: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: CI Discovered By: User Report Severity: Critical Status: Open (was: Triage Needed) > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17563) Fix CircleCI Midres config
Ekaterina Dimitrova created CASSANDRA-17563: --- Summary: Fix CircleCI Midres config Key: CASSANDRA-17563 URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova During CircleCI addition of a new job to the config, the midres file got messy. Two of the immediate issues (but we need to verify all jobs will use the right executors and resources): * the new job needs to use higher parallelism as the original in-jvm job * j8_dtests_with_vnodes should get from midres 50 large but currently midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17258) Block writes to partitions over a threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524608#comment-17524608 ] David Capwell commented on CASSANDRA-17258: --- blockers are almost all resolved, will try to pick this up before 4.1, but if not won't block 4.1 on this patch > Block writes to partitions over a threshold > --- > > Key: CASSANDRA-17258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17258 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > With CASSANDRA-16310 we now know (node local) the top partitions (size and > number of tombstones) and can leverage this to block adding writes to > partitions over a given size (as defined by top partitions). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524602#comment-17524602 ] Ekaterina Dimitrova edited comment on CASSANDRA-17431 at 4/19/22 10:11 PM: --- So I reran in a loop the test on trunk with the patch: 130 times out of 4000 J8 and 89 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/a1508c6d-7d81-4f05-b6bf-e763ca73d4d0] 149 on J11 - 80 containers failing - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/d7d7b147-79a2-4711-8394-a1747c1db140] and without the patch: 109 times out of 4000 J8 and 105 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/6b89f85b-083e-4ed6-9493-68e39118f56d] J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/acc8c0b8-7387-4470-902e-c5ffd33a7052/jobs/10308/parallel-runs/0?filterBy=FAILED] No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. Without the patch - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1561/workflows/bdfaad5a-c46c-4606-9f8b-1c6cdd7c2886 With the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1560/workflows/251996d8-b57c-4c35-b293-e1fd0d158a1c] was (Author: e.dimitrova): So I reran in a loop the test on trunk with the patch: 130 times out of 4000 J8 and 89 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/a1508c6d-7d81-4f05-b6bf-e763ca73d4d0] 149 on J11 - 80 containers failing - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/d7d7b147-79a2-4711-8394-a1747c1db140] and without the patch: 109 times out of 4000 J8 and 105 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/6b89f85b-083e-4ed6-9493-68e39118f56d] J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/acc8c0b8-7387-4470-902e-c5ffd33a7052/jobs/10308/parallel-runs/0?filterBy=FAILED] No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. Without the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1559/workflows/e5b8f084-1897-4ff1-9abf-4d390435bfd4] With the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1560/workflows/251996d8-b57c-4c35-b293-e1fd0d158a1c] > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524602#comment-17524602 ] Ekaterina Dimitrova edited comment on CASSANDRA-17431 at 4/19/22 10:07 PM: --- So I reran in a loop the test on trunk with the patch: 130 times out of 4000 J8 and 89 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/a1508c6d-7d81-4f05-b6bf-e763ca73d4d0] 149 on J11 - 80 containers failing - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/d7d7b147-79a2-4711-8394-a1747c1db140] and without the patch: 109 times out of 4000 J8 and 105 times out of 4000 J11 on J8 - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/6b89f85b-083e-4ed6-9493-68e39118f56d] J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/acc8c0b8-7387-4470-902e-c5ffd33a7052/jobs/10308/parallel-runs/0?filterBy=FAILED] No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. Without the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1559/workflows/e5b8f084-1897-4ff1-9abf-4d390435bfd4] With the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1560/workflows/251996d8-b57c-4c35-b293-e1fd0d158a1c] was (Author: e.dimitrova): So I reran in a loop the test with trunk with: 130 times out of 4000 J8 and 89 times out of 4000 J11 on J8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/a1508c6d-7d81-4f05-b6bf-e763ca73d4d0 149 on J11 - 80 containers failing - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/d7d7b147-79a2-4711-8394-a1747c1db140 and without the patch: 109 times out of 4000 J8 and 105 times out of 4000 J11 on J8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/6b89f85b-083e-4ed6-9493-68e39118f56d J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/acc8c0b8-7387-4470-902e-c5ffd33a7052/jobs/10308/parallel-runs/0?filterBy=FAILED No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. Without the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1559/workflows/e5b8f084-1897-4ff1-9abf-4d390435bfd4] With the patch - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1560/workflows/251996d8-b57c-4c35-b293-e1fd0d158a1c > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524602#comment-17524602 ] Ekaterina Dimitrova edited comment on CASSANDRA-17431 at 4/19/22 10:07 PM: --- So I reran in a loop the test with trunk with: 130 times out of 4000 J8 and 89 times out of 4000 J11 on J8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/a1508c6d-7d81-4f05-b6bf-e763ca73d4d0 149 on J11 - 80 containers failing - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1557/workflows/d7d7b147-79a2-4711-8394-a1747c1db140 and without the patch: 109 times out of 4000 J8 and 105 times out of 4000 J11 on J8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/6b89f85b-083e-4ed6-9493-68e39118f56d J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1558/workflows/acc8c0b8-7387-4470-902e-c5ffd33a7052/jobs/10308/parallel-runs/0?filterBy=FAILED No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. Without the patch - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1559/workflows/e5b8f084-1897-4ff1-9abf-4d390435bfd4] With the patch - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1560/workflows/251996d8-b57c-4c35-b293-e1fd0d158a1c was (Author: e.dimitrova): So I reran in a loop the test with trunk with: 130 times out of 4000 J8 89 times out of 4000 J11 on J8 149 on J11 - 80 containers failing and without the patch: 109 times out of 4000 J8 105 times out of 4000 J11 on J8 J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524602#comment-17524602 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - So I reran in a loop the test with trunk with: 130 times out of 4000 J8 89 times out of 4000 J11 on J8 149 on J11 - 80 containers failing and without the patch: 109 times out of 4000 J8 105 times out of 4000 J11 on J8 J11 - Circle shows only failed containers - 86 and not number of failed tests but considering the amount of failed containers I don't expect different results. No new errors - only the two types we've seen before, the null pointer and the assertion error. I think my suspicion was wrong. Now running in the loop 1 upgrade test which I haven't seen before. The rest are known issues which have tickets already. > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524591#comment-17524591
]
David Capwell commented on CASSANDRA-16310:
---
Patch LGTM, I had minor nits for the type change, but those can be done on
merge or ignored
+1
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17180: - Reviewers: Brandon Williams, Paulo Motta (was: Paulo Motta) > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 8h > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17562) Add additional new JMX methods for the old Config migrated to the new types
[ https://issues.apache.org/jira/browse/CASSANDRA-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17562: Change Category: Operability Complexity: Low Hanging Fruit Component/s: Local/Config Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > Add additional new JMX methods for the old Config migrated to the new types > --- > > Key: CASSANDRA-17562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17562 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > In CASSANDRA-15234 we migrated config parameters to new types. The old JMX > methods which use primitives are still working as expected. We need to add > also new JMX methods for the new types, the getters/setters will get/set > String until write mode is added to the Settings virtual table. > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17562) Add additional new JMX methods for the old Config migrated to the new types
[ https://issues.apache.org/jira/browse/CASSANDRA-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17562: Fix Version/s: 4.x > Add additional new JMX methods for the old Config migrated to the new types > --- > > Key: CASSANDRA-17562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17562 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In CASSANDRA-15234 we migrated config parameters to new types. The old JMX > methods which use primitives are still working as expected. We need to add > also new JMX methods for the new types, the getters/setters will get/set > String until write mode is added to the Settings virtual table. > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17562) Add additional new JMX methods for the old Config migrated to the new types
[ https://issues.apache.org/jira/browse/CASSANDRA-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17562: Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug Workflow) Issue Type: Task (was: Bug) > Add additional new JMX methods for the old Config migrated to the new types > --- > > Key: CASSANDRA-17562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17562 > Project: Cassandra > Issue Type: Task >Reporter: Ekaterina Dimitrova >Priority: Normal > > In CASSANDRA-15234 we migrated config parameters to new types. The old JMX > methods which use primitives are still working as expected. We need to add > also new JMX methods for the new types, the getters/setters will get/set > String until write mode is added to the Settings virtual table. > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17562) Add additional new JMX methods for the old Config migrated to the new types
Ekaterina Dimitrova created CASSANDRA-17562: --- Summary: Add additional new JMX methods for the old Config migrated to the new types Key: CASSANDRA-17562 URL: https://issues.apache.org/jira/browse/CASSANDRA-17562 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova In CASSANDRA-15234 we migrated config parameters to new types. The old JMX methods which use primitives are still working as expected. We need to add also new JMX methods for the new types, the getters/setters will get/set String until write mode is added to the Settings virtual table. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Summary: Implement startup check to prevent Cassandra start to spread zombie data (was: Implement heartbeat service to know last time Cassandra node was up) > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 6h 50m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524479#comment-17524479
]
Ekaterina Dimitrova commented on CASSANDRA-17451:
-
For the record, I noticed some class cast exception in the logs the other day,
not sure what is the story there. Hope that info is useful.
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17530:
Reviewers: Blake Eggleston, Blake Eggleston (was: Blake Eggleston)
Blake Eggleston, Blake Eggleston (was: Blake Eggleston)
Status: Review In Progress (was: Patch Available)
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17530:
Status: Ready to Commit (was: Review In Progress)
Looks good, +1
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17530:
Reviewers: Blake Eggleston
Description:
The version of Paxos introduced recently had a subtle mistake that introduced
a linearizability flaw that has been detected by the simulator, and also a flaw
with the simulator has been found that may erroneously report a linearizability
violation.
The true linearizability fault is quite simple: fast read permissions were
erroneously being escalated to promises when an incomplete proposal was
discovered. This was likely due in part to the naming of the state
{{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
be used to re-propose this proposal using the promises we have obtained. The
fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
The false linearizability fault was triggered when two different competing
incomplete proposals were reproposed multiple times, with the winning proposal
being the one with the lower original ballot, and the proposal with the higher
ballot having been successfully proposed to a majority of nodes but across
multiple different ballots (so that no single ballot reached a majority), while
the most recently successful ballot (at a minority) was the older original
ballot. The range movement validation logic looked only at the original ballot,
and since it saw the higher original ballot as having reached a majority
perceived that it should have become persistent, when in fact the older ballot
did so.
was:
The version of Paxos introduced recently had a subtle mistake that introduced
a linearizability flaw that has been detected by the simulator, and also a flaw
with the simulator has been found that may erroneously report a linearizability
violation.
The true linearizability fault is quite simple: fast read permissions were
erroneously being escalated to promises when an incomplete proposal was
discovered. This was likely due in part to the naming of the state
{{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
be used to re-propose this proposal using the promises we have obtained. The
fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
The false linearizability fault was triggered when two different competing
incomplete proposals were reproposed multiple times, with the winning proposal
being the one with the lower original ballot, and the proposal with the higher
ballot having been successfully proposed to a majority of nodes but across
multiple different ballots (so that no single ballot reached a majority), while
the most recently successful ballot (at a minority) was the older original
ballot. The range movement validation logic looked only at the original ballot,
and since it saw the higher original ballot as having reached a majority
perceived that it should have become persistent, when in fact the older ballot
did so.
> Paxos v2 Linearizability Violation
> --
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by
[jira] [Assigned] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17451:
Assignee: Brandon Williams
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524463#comment-17524463
]
David Capwell commented on CASSANDRA-17212:
---
dumping context here:
Current logic was not released, but has a few bugs that this patch should
address, and if not able to address in time for the May first free should be
moved to its own JIRA and fixed
* system key spaces are included in this check
* check is called outside of CREATE/ALTER KEYSPACE, which can cause a instance
to fail to startup
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17558) Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17558: -- Status: Ready to Commit (was: Review In Progress) +1 > Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser > accounts > > > Key: CASSANDRA-17558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17558 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While this can also be accomplished via roles, there's value in having a > cluster-wide "all role ban" on specific operations that operators can > configure for clusters that have need of those settings. > In this case, we want the ability to completely disallow DROP or TRUNCATE > TABLE commands so users cannot inadvertently throw away data and operators > don't have to runbook managing roles to ensure that this functionality > doesn't leak through. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17558) Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17558: -- Status: Review In Progress (was: Patch Available) > Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser > accounts > > > Key: CASSANDRA-17558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17558 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While this can also be accomplished via roles, there's value in having a > cluster-wide "all role ban" on specific operations that operators can > configure for clusters that have need of those settings. > In this case, we want the ability to completely disallow DROP or TRUNCATE > TABLE commands so users cannot inadvertently throw away data and operators > don't have to runbook managing roles to ensure that this functionality > doesn't leak through. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17558) Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser accounts
[ https://issues.apache.org/jira/browse/CASSANDRA-17558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17558: -- Reviewers: Aleksey Yeschenko > Add guardrail to disallow DROP or TRUNCATE TABLE commands for non superuser > accounts > > > Key: CASSANDRA-17558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17558 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While this can also be accomplished via roles, there's value in having a > cluster-wide "all role ban" on specific operations that operators can > configure for clusters that have need of those settings. > In this case, we want the ability to completely disallow DROP or TRUNCATE > TABLE commands so users cannot inadvertently throw away data and operators > don't have to runbook managing roles to ensure that this functionality > doesn't leak through. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17560: -- Reviewers: Andres de la Peña, Caleb Rackliffe (was: Caleb Rackliffe) > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17560: Fix Version/s: 4.1 > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17560) Migrate track_warnings to more standard naming conventions and use latest configuration types rather than long
[ https://issues.apache.org/jira/browse/CASSANDRA-17560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17560: Status: Ready to Commit (was: Review In Progress) +1 > Migrate track_warnings to more standard naming conventions and use latest > configuration types rather than long > -- > > Key: CASSANDRA-17560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17560 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Priority: Normal > Time Spent: 2h 20m > Remaining Estimate: 0h > > Track warnings currently is nested which is discouraged at the moment. It > also was before the config standards patch which moved storage typed longs to > a new DataStorageSpec type, we should migrate the configs there. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524382#comment-17524382 ] Brian Houser edited comment on CASSANDRA-16456 at 4/19/22 3:27 PM: --- Ok made change to I'll remove the [plain_text_auth] functionality from the creds file.,. I did run pylint but only on my file. As for combining the authentication section with auth_provider, I elected not to do this. Primarily because auth_provider is meant for loading a custom plugin, and is dynamically loading properties found in the section. Adding it to authentication section means making it a bit fuzzy as to what is a reserved property and what should match the constructor of the imported library, it offers the potential for namespace conflicts if we ever add other general auth properties, for this reason I'd prefer to keep it clean and distinct. was (Author: bhouser): Ok made change to I'll remove the [plain_text_auth] functionality from the creds file.,. I did run pylint but only on my file. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524382#comment-17524382 ] Brian Houser commented on CASSANDRA-16456: -- Ok made change to I'll remove the [plain_text_auth] functionality from the creds file.,. I did run pylint but only on my file. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Fix Version/s: 4.x > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Test and Documentation Plan: new test, cci run Status: Patch Available (was: Open) https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Fsnapshot_mismatching_ranges=all https://github.com/apache/cassandra/pull/1577 > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Change Category: Quality Assurance Complexity: Low Hanging Fruit Reviewers: Sam Tunnicliffe Status: Open (was: Triage Needed) > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
Marcus Eriksson created CASSANDRA-17561: --- Summary: Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch Key: CASSANDRA-17561 URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 Project: Cassandra Issue Type: Improvement Components: Consistency/Repair Reporter: Marcus Eriksson Assignee: Marcus Eriksson We currently snapshot all sstables in a table when a preview repair mismatch occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10709) Synchronize TOC and digest
[ https://issues.apache.org/jira/browse/CASSANDRA-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524206#comment-17524206 ] Maciej Sokol commented on CASSANDRA-10709: -- [3.0|https://github.com/apache/cassandra/pull/1574] [3.0 CI|https://app.circleci.com/pipelines/github/masokol/cassandra/8/workflows/2bdb7ace-27fb-4d04-b524-fa7bc6df7224] [3.11|https://github.com/apache/cassandra/pull/1566] [3.11 CI|https://app.circleci.com/pipelines/github/masokol/cassandra/3/workflows/cb9329bd-8806-4951-8ba4-8eb6e5bd7959] [4.0|https://github.com/apache/cassandra/pull/1575] [4.0 CI J8|https://app.circleci.com/pipelines/github/masokol/cassandra/9/workflows/ee75fb11-41ad-499b-ac93-8084b97cadda] [4.0 CI J11|https://app.circleci.com/pipelines/github/masokol/cassandra/9/workflows/40816157-7d3a-43b6-a706-d3c6f2d396d9] [trunk|https://github.com/apache/cassandra/pull/1576] [trunk CI J8|https://app.circleci.com/pipelines/github/masokol/cassandra/10/workflows/bd9aeaeb-d295-4633-90c6-fc1083490235] [trunk CI J11|https://app.circleci.com/pipelines/github/masokol/cassandra/10/workflows/a4c09f26-6416-4c5b-a298-365316e1fec4] If someone could review that would be great. Also CI might need to be rerun because i don't have paid circleci. > Synchronize TOC and digest > -- > > Key: CASSANDRA-10709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10709 > Project: Cassandra > Issue Type: Bug >Reporter: Stefania Alborghetti >Assignee: Maciej Sokol >Priority: Low > Fix For: 2.2.x, 3.11.x > > > The TOC and DIGEST components are not synchronized at the moment (the file is > not fsynch-ed to disk after it is written). This could cause inconsistencies > in case of power failures. At the moment these component sstable files are > only used by standalone tools but we should fix them nonetheless. > Refer to the discussion on CASSANDRA-10534 for more details. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524198#comment-17524198
]
Berenguer Blasi commented on CASSANDRA-10537:
-
I haven't forgotten about this one. I am just hitting some weird errors I am
trying to pin down #justfyi
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524185#comment-17524185
]
Marcus Eriksson commented on CASSANDRA-17379:
-
PR updated with the above
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524170#comment-17524170
]
Ekaterina Dimitrova edited comment on CASSANDRA-17379 at 4/19/22 8:23 AM:
--
Should we add a flag - by default disallow the usage old no matter of the
value and if they want - they can opt in for allowing them together no matter
of the value, at their own risk?
was (Author: e.dimitrova):
Should we add a flag - by default disallow the usage old no matter of the
value and if they want - they can opt in for allowing them together no matter
of the value at their own risk?
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524170#comment-17524170
]
Ekaterina Dimitrova commented on CASSANDRA-17379:
-
Should we add a flag - by default disallow the usage old no matter of the
value and if they want - they can opt in for allowing them together no matter
of the value at their own risk?
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r53960 - in /dev/cassandra/4.0.4/redhat: ./ repodata/
Author: mck Date: Tue Apr 19 08:16:26 2022 New Revision: 53960 Log: staging cassandra rpm packages for 4.0.4 Added: dev/cassandra/4.0.4/redhat/ dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.noarch.rpm (with props) dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.src.rpm (with props) dev/cassandra/4.0.4/redhat/cassandra-tools-4.0.4-1.noarch.rpm (with props) dev/cassandra/4.0.4/redhat/repodata/ dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2 (with props) dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2.asc dev/cassandra/4.0.4/redhat/repodata/4be28f794ee0b84ac7c4996756ee04717edfbd9e213873f7090c7e25ac380da0-primary.xml.gz (with props) dev/cassandra/4.0.4/redhat/repodata/4be28f794ee0b84ac7c4996756ee04717edfbd9e213873f7090c7e25ac380da0-primary.xml.gz.asc dev/cassandra/4.0.4/redhat/repodata/74cf0e4b685e7b3e877c0c3ee41b40ae4358b11388fac992e63c5b0ea0507a45-other.sqlite.bz2 (with props) dev/cassandra/4.0.4/redhat/repodata/74cf0e4b685e7b3e877c0c3ee41b40ae4358b11388fac992e63c5b0ea0507a45-other.sqlite.bz2.asc dev/cassandra/4.0.4/redhat/repodata/9031e94e914ca83bb063d501c2322b6fb7ade2be87c03bc0fa0e28ae432f-filelists.xml.gz (with props) dev/cassandra/4.0.4/redhat/repodata/9031e94e914ca83bb063d501c2322b6fb7ade2be87c03bc0fa0e28ae432f-filelists.xml.gz.asc dev/cassandra/4.0.4/redhat/repodata/e7570b9bcd8665a578e058ea1a7517306610985ec11faaec7580f64095d0071b-primary.sqlite.bz2 (with props) dev/cassandra/4.0.4/redhat/repodata/e7570b9bcd8665a578e058ea1a7517306610985ec11faaec7580f64095d0071b-primary.sqlite.bz2.asc dev/cassandra/4.0.4/redhat/repodata/f004c06bb6226e570688baae9bcff99ec71a902d2d9d734275c25fc75fa1a837-other.xml.gz (with props) dev/cassandra/4.0.4/redhat/repodata/f004c06bb6226e570688baae9bcff99ec71a902d2d9d734275c25fc75fa1a837-other.xml.gz.asc dev/cassandra/4.0.4/redhat/repodata/repomd.xml dev/cassandra/4.0.4/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/redhat/cassandra-4.0.4-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/redhat/cassandra-tools-4.0.4-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/redhat/cassandra-tools-4.0.4-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2.asc == --- dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2.asc (added) +++ dev/cassandra/4.0.4/redhat/repodata/0c2ebfefd5e27da48aa994b801a2c339c77dfdf2c4496158a30f1884b0698b02-filelists.sqlite.bz2.asc Tue Apr 19 08:16:26 2022 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmJeb8EACgkQ6RM1134+ +h8tskBAAsjKi6jiBB8L9IrdWc1IFqEpOMotJZn0jt/mdAyQ+nSB5mu2curPrUS55 +oI50tQvblt8Rhz+A6V0TnggBqF2i9+E+/pz2t8wHKPS2aZoJQFHpCkJyO9LK5XCm +2ok07SrbAvumTFaeOyYy4Oi30sQmYmsZuZdfgvgrClET8FTFTcVXu+8HSp78+PW5 +ZlZJN22yZLIVGRR3u7Ku0tultgSNnKnqrdxOykKs/VT8iaAZuD3HhSwo6WI36Yvq +osExuswQTVVcyzHjqap71nJNiX4SPwDKPvjOHNZZulETA1ookWDh1nH5bylyon6J +Ve0ZtX7a0MkT7pocUFKHCmBz2BPpIAwtg64U0IcPaEwN/nKOiJ1xBxS16eDzuYaE +4MXpTgWVmo7Aru8bSJudpMFvdjQoIU9pNOxnxOkws8RY4+MMkpL9C67yXZ8xYvpj +fpx/eTQbjPDt4iTiMQCfx7NIY9FSwgBDKfznNSAr3t5AfXLp7p8STdjYYEl1AJp3 +G/MJNoyiwq/s9as+g3jWAL6mPhTzCWwfK5b2I0vP6FHjmzexEQw7ytEqLMhthEuD
svn commit: r53959 - in /dev/cassandra/4.0.4/debian: ./ dists/ dists/40x/ dists/40x/main/ dists/40x/main/binary-amd64/ dists/40x/main/binary-arm64/ dists/40x/main/binary-i386/ dists/40x/main/source/ p
Author: mck Date: Tue Apr 19 08:06:38 2022 New Revision: 53959 Log: staging cassandra debian packages for 4.0.4 Added: dev/cassandra/4.0.4/debian/ dev/cassandra/4.0.4/debian/cassandra-tools_4.0.4_all.deb (with props) dev/cassandra/4.0.4/debian/cassandra_4.0.4.dsc dev/cassandra/4.0.4/debian/cassandra_4.0.4.tar.gz (with props) dev/cassandra/4.0.4/debian/cassandra_4.0.4_all.deb (with props) dev/cassandra/4.0.4/debian/cassandra_4.0.4_amd64.buildinfo dev/cassandra/4.0.4/debian/cassandra_4.0.4_amd64.changes dev/cassandra/4.0.4/debian/dists/ dev/cassandra/4.0.4/debian/dists/40x/ dev/cassandra/4.0.4/debian/dists/40x/InRelease dev/cassandra/4.0.4/debian/dists/40x/Release dev/cassandra/4.0.4/debian/dists/40x/Release.gpg dev/cassandra/4.0.4/debian/dists/40x/main/ dev/cassandra/4.0.4/debian/dists/40x/main/binary-amd64/ dev/cassandra/4.0.4/debian/dists/40x/main/binary-amd64/Packages dev/cassandra/4.0.4/debian/dists/40x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.0.4/debian/dists/40x/main/binary-amd64/Release dev/cassandra/4.0.4/debian/dists/40x/main/binary-arm64/ dev/cassandra/4.0.4/debian/dists/40x/main/binary-arm64/Packages dev/cassandra/4.0.4/debian/dists/40x/main/binary-arm64/Packages.gz (with props) dev/cassandra/4.0.4/debian/dists/40x/main/binary-arm64/Release dev/cassandra/4.0.4/debian/dists/40x/main/binary-i386/ dev/cassandra/4.0.4/debian/dists/40x/main/binary-i386/Packages dev/cassandra/4.0.4/debian/dists/40x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.0.4/debian/dists/40x/main/binary-i386/Release dev/cassandra/4.0.4/debian/dists/40x/main/source/ dev/cassandra/4.0.4/debian/dists/40x/main/source/Release dev/cassandra/4.0.4/debian/dists/40x/main/source/Sources.gz (with props) dev/cassandra/4.0.4/debian/pool/ dev/cassandra/4.0.4/debian/pool/main/ dev/cassandra/4.0.4/debian/pool/main/c/ dev/cassandra/4.0.4/debian/pool/main/c/cassandra/ dev/cassandra/4.0.4/debian/pool/main/c/cassandra/cassandra-tools_4.0.4_all.deb (with props) dev/cassandra/4.0.4/debian/pool/main/c/cassandra/cassandra_4.0.4.dsc dev/cassandra/4.0.4/debian/pool/main/c/cassandra/cassandra_4.0.4.tar.gz (with props) dev/cassandra/4.0.4/debian/pool/main/c/cassandra/cassandra_4.0.4_all.deb (with props) Added: dev/cassandra/4.0.4/debian/cassandra-tools_4.0.4_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/debian/cassandra-tools_4.0.4_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/debian/cassandra_4.0.4.dsc == --- dev/cassandra/4.0.4/debian/cassandra_4.0.4.dsc (added) +++ dev/cassandra/4.0.4/debian/cassandra_4.0.4.dsc Tue Apr 19 08:06:38 2022 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.0.4 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://gitbox.apache.org/repos/asf?p=cassandra.git +Vcs-Git: https://gitbox.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 11), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python3-dev (>= 3.6), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 954aecd44740e62af76ab423fd96ccb3a233131f 234321991 cassandra_4.0.4.tar.gz +Checksums-Sha256: + e97a7ee2c0361e9c5b247c0ef2be0ca21cd4e1886a7321ac1a511466d8e59709 234321991 cassandra_4.0.4.tar.gz +Files: + 27ad26e10c54f7abb563f8bfcb76d051 234321991 cassandra_4.0.4.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmJebNQACgkQ6RM1134+ +h8swQw//cSTILr0JVb0HD73RbqirpxQrOtGXzAQqdjLmzOLvn8bOkOxVIgNSVGAp +QapSRx8H9GknykFbmfuD97pwdABSYX06PnoqYr21hhMVhhwRYA/H0VrJ5RD4fRpk +mY+q3uMVL0pkCgI5+BU3Ced+T2vg9g5E+B5kI3RfrPVzO4P1ygpwHOomAsY++UpP +ixZqj5J1dxlH6wW6uDaYR23F69AQ8wFo4ZZ5QHusCs+RkGGAqe8cKUegnv7M8YCG +YYwl8Z69NZUdF3QLdM/aG8vKbubhjtCRyt7IqGe594wlto1bGdjD7+mTsWdTIAbZ +LzauSoZfE4+RBksI0DhHOnRbvIdPQcgq71dEzHwmRbP/eMZZjP57fFL920qyg9EX +h6WWD73oJkQBm/w5yykiAw0oX/cHwLMXvjrhL7BF99A/N+ogy/X3+UluU1CZD66k +qxrzrS5wEpZLHvvDrC89ZXAstn4ZiZbJ8g95mTWcpBOlBbxMkkh2sOPKdk6m7Slo +U5zMmdVHD+abdIWN3lIwR8Fh7bArnfGJ/R8fVPGvTzVi8WGwuqWIqp3AQlXExcCE +uYXO3vE5QOeBkxFYwmRAnGuKl3bVHsnezhXAMAV3pcmDEHm2MTzyJ2vxZnP775R2 +3IDGj/X80JcrhO1Nntf/ewoxshsRB2JTWapn375KehelPVTTbcY= +=IT2L +-END PGP SIGNATURE- Added: dev/cassandra/4.0.4/debian/cassandra_4.0.4.tar.gz == Binary file - no
svn commit: r53958 - /dev/cassandra/4.0.4/
Author: mck Date: Tue Apr 19 07:54:15 2022 New Revision: 53958 Log: staging cassandra 4.0.4 Added: dev/cassandra/4.0.4/ dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz (with props) dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.asc dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha256 dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha512 dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz (with props) dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.asc dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.sha256 dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.sha512 Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.asc == --- dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.asc (added) +++ dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.asc Tue Apr 19 07:54:15 2022 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmJeZycACgkQ6RM1134+ +h8vvtw/9H52sMj2DU86UJNmSrK5AJ7wQEVgIus6eEt2XKnNzdAnb3mSfUkSszWyd +jdKDFkhUNxu2We+xoFmcaOnhAEvreQeXI+3rrEJhQEJfvCRFCQbe0c9feNnFlS7q +dYvilOi0GwjGo+PIdlSUb1OFK/T1WOu7VX2/h9BEAgLeYVj241GatEd67BG1GQUi +SySLScandQyNC5ivWYf0P/iMApbsjBmfFAahBxYqw5bkMMAr2tRZ484jtN/zlk5Z +vDgy/ooo7SZSH5W0wHP6itp7jZcarvKVz9TyONL2I0LqdcSsMm2yYZFZcTSKc/p1 +2BYMghRD6HD4dGpsENs3x9kNtJmRNx6axpc3b3pDCvRFaKgXogrpD9xHpy3BcO2N +YgKCpvYFwLBIr75uTmrXz0sHxhygAC4WuSKsWkibNq6GhPvS59KpVfZWXMlO5rke +0r/qLOLrn1639Cfr0AIbG2u/jO+HdDddeTV2fU2z5M+2NpLolOuvxdshWOQhS9Ww +TRPFOeGUoGAV1vq7y9bG5orUWdAuCDd7bdDKdhtVnkGVxF730ngxR3fKVtWJxG3L +yhZmbgnU3ZT/+m1Q/Hk59EZYbH3vLecA5+29BE8jZGLSkGslE6nwqidWc6f6UXcP +Oi2EP+DO3jJmPPDG1wEbdNY3/jZHNdh/7nfpdRVd2UHXiMbxxJA= +=aLAl +-END PGP SIGNATURE- Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha256 == --- dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha256 Tue Apr 19 07:54:15 2022 @@ -0,0 +1 @@ +7e4676f1e6408856696675880df46bec85b75b8f42d7c4528623d3a4d909dc10 Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha512 == --- dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.0.4/apache-cassandra-4.0.4-bin.tar.gz.sha512 Tue Apr 19 07:54:15 2022 @@ -0,0 +1 @@ +3458bfa93e29c5066e7f8a35380d3c710d7e6f451e70ba4dfa6f47529b0accb58181f864591ab539a6ca1ef58f33a804fc9d1df03e5a6b198136e32667b86aa9 Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.asc == --- dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.asc (added) +++ dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.asc Tue Apr 19 07:54:15 2022 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmJeZyoACgkQ6RM1134+ +h8s2dg//UdGNkdsNF+V4Br2LOlXDyLYNo9b3JuPezq60JE8IJfx3oExCr0fJa1CG +J6UzydhzQso/UEVFyFo/pXO3rQAQqeihXCNO6P3oes9cRJTC/zgQbYelLUKnJMxV +gEIw6wNepRyhwvTwvU3wgSjQtuvC1aaIpc21KUXER4nsCQS9mL1mY3fejLa98RlQ +Vfgn8k4qXnCRq9K9ETFvr6P8iFXqNO6wfMbYyFS0+7PZkecVDZ09vH5B0UuAz04L +sxyhh8Y0bB0lU/dVQrwHe5p4rcObyl+YWk1i8jR6EkGgCIla99rSYqtKs3YeaWF/ +sVdb49FrHiWzUEs9nYhcKvrOhb2ClKmaW1amCg15xKXMYTEpqaBoMPt8hk1YSOGl +urPDKni4IFboAU9osXm1U0pyudwGXS6ovshQGqT2x9sdCdQ0TSVVyV27ojMFkphs +y0PxRFf5LzCCMCreKh9HnPNSbCEZxKXizgCtGvJVOhwbSh7e7yQ3nzFkKXhr7Hgd +WlGmD389z2C00m8JbbbDSEdUiKpVmT0jWOsJP62jQxrf05ERKmCOZjHrnGQS73lC +84rotgU65KObtr6dGEcV2ViC/HB4LjZ6KFXV8ALOee1tUdgX9yBP/dRwOau9re7v +tKfAs9Mbl0LVyQPQjuIyHNtpdDYcBrfvnzwIcAikq9cVvLB6PqU= +=UTvu +-END PGP SIGNATURE- Added: dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.sha256 == --- dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.sha256 (added) +++ dev/cassandra/4.0.4/apache-cassandra-4.0.4-src.tar.gz.sha256 Tue Apr 19 07:54:15 2022 @@ -0,0 +1 @@ +275065a1c6c1dc83d9489c102469b0ba4a2bb7074c390fb635aa984e921bac09 Added:
[cassandra] 01/01: Prepare debian changelog for 4.0.4
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to tag 4.0.4-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c8cfaf449763d51346840a968c3a687ac3297a7f Author: Mick Semb Wever AuthorDate: Tue Apr 19 09:33:50 2022 +0200 Prepare debian changelog for 4.0.4 --- debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index d6f69fd636..b1f3433889 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,8 @@ -cassandra (4.0.4) UNRELEASED; urgency=medium +cassandra (4.0.4) unstable; urgency=medium * New release - -- Mick Semb Wever Sun, 13 Feb 2022 22:37:37 +0100 + -- Mick Semb Wever Tue, 19 Apr 2022 09:33:23 +0200 cassandra (4.0.3) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0.4-tentative created (now c8cfaf4497)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0.4-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at c8cfaf4497 (commit) This tag includes the following new commits: new c8cfaf4497 Prepare debian changelog for 4.0.4 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524133#comment-17524133
]
Marcus Eriksson commented on CASSANDRA-17379:
-
I'm +1 disallowing new + old config params even if the value is the same
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524130#comment-17524130
]
Marcus Eriksson commented on CASSANDRA-16310:
-
rebased and a small update (use DataStorageSpec for the min partition size
config param) now that CASSANDRA-14752 has been merged:
https://github.com/krummas/cassandra/commits/marcuse/16310
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16310
[~dcapwell] could you have a final look before I commit this?
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
