[jira] [Updated] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Michael Semb Wever (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17050:
---
Fix Version/s: 4.x
   3.11.x
   3.0.x
   2.2.x
 Severity: Critical  (was: Normal)

Raising priority as CI is trashed until this gets out.

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17063) Make capacity/validity/updateinterval for Auth Caches configurable via nodetool

2021-10-25 Thread Benjamin Lerer (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433607#comment-17433607
 ] 

Benjamin Lerer commented on CASSANDRA-17063:


[~azotcsit] I guess that what you are looking for is CASSANDRA-15254.

> Make capacity/validity/updateinterval for Auth Caches configurable via 
> nodetool
> ---
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options 
> (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to 
> introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to _nodetool_. But I feel 
> there is no need to have a separate table for Auth Caches configs. It would 
> be an overhead. Ideally we need to have a separate VT that shows/sets all the 
> configs, but it is out of the scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Michael Semb Wever (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433609#comment-17433609
 ] 

Michael Semb Wever commented on CASSANDRA-17050:


The patches don't build, because they don't pass the `ant dependency-check` 
which now fail on all branches because of a new CVE in 
netty-all-4.0.44.Final.jar



> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Berenguer Blasi (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433610#comment-17433610
 ] 

Berenguer Blasi commented on CASSANDRA-16996:
-

All rebased, fixed, squahsed + new CI for a final check otherwise I'll merge.

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0, 4.x
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra-builds] branch trunk updated: disabling dependency checks

2021-10-25 Thread smiklosovic
This is an automated email from the ASF dual-hosted git repository.

smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git


The following commit(s) were added to refs/heads/trunk by this push:
 new b994726  disabling dependency checks
b994726 is described below

commit b994726be5f5800889134dd0b81e7d483cbee619
Author: Stefan Miklosovic 
AuthorDate: Mon Oct 25 09:59:52 2021 +0200

disabling dependency checks
---
 build-scripts/cassandra-artifacts.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-scripts/cassandra-artifacts.sh 
b/build-scripts/cassandra-artifacts.sh
index 0e51778..80185f9 100755
--- a/build-scripts/cassandra-artifacts.sh
+++ b/build-scripts/cassandra-artifacts.sh
@@ -50,7 +50,8 @@ set +e # disable immediate exit from this point
 ARTIFACTS_BUILD_RUN=0
 ECLIPSE_WARNINGS_RUN=0
 
-HAS_DEPENDENCY_CHECK_TARGET=$(ant -p build.xml | grep "dependency-check " | wc 
-l)
+#HAS_DEPENDENCY_CHECK_TARGET=$(ant -p build.xml | grep "dependency-check " | 
wc -l)
+HAS_DEPENDENCY_CHECK_TARGET=0
 # versions starting from 6.4.1 contain "rate limiter" functionality to make 
builds more stable
 # https://github.com/jeremylong/DependencyCheck/pull/3725
 DEPENDENCY_CHECK_VERSION=6.4.1

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17063) Make capacity/validity/updateinterval for Auth Caches configurable via nodetool

2021-10-25 Thread Aleksei Zotov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433613#comment-17433613
 ] 

Aleksei Zotov commented on CASSANDRA-17063:
---

Great, thanks [~blerer]! That's exactly what I was looking for.

> Make capacity/validity/updateinterval for Auth Caches configurable via 
> nodetool
> ---
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options 
> (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to 
> introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to _nodetool_. But I feel 
> there is no need to have a separate table for Auth Caches configs. It would 
> be an overhead. Ideally we need to have a separate VT that shows/sets all the 
> configs, but it is out of the scope.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16801) PasswordObfuscator should not assume PASSWORD is the last item in the WITH clause

2021-10-25 Thread Berenguer Blasi (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433618#comment-17433618
 ] 

Berenguer Blasi commented on CASSANDRA-16801:
-

Will be looking into this one in short #justfyi

> PasswordObfuscator should not assume PASSWORD is the last item in the WITH 
> clause
> -
>
> Key: CASSANDRA-16801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16801
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/auditlogging
>Reporter: Caleb Rackliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> CASSANDRA-16669 introduced support for obfuscating passwords for audit log 
> statements, but there are a few cases where the obfuscation logic can destroy 
> some of the contents of the original/provided string.
> ex. This is perfectly valid...
> {noformat}
> WITH LOGIN = false AND PASSWORD = 'bar' AND SUPERUSER = false
> {noformat}
> ...but calling obfuscate() on it will produce...
> {noformat}
> WITH LOGIN = false AND PASSWORD ***
> {noformat}
> -We should be able to create a reasonable RegEx and use String#replaceAll() 
> to both simplify and correct PasswordObfuscator#obfuscate().-



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Alex Petrov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433642#comment-17433642
 ] 

Alex Petrov commented on CASSANDRA-17044:
-

Thank you for the patch and clarifications. I like the overall direction 
towards modularisation and interfaces. My comments are following.
 * Even though I generally like that {{SchemaChangeListener}} is now an 
interface rather than abstract class, I’m concerned about potential users who 
might have relied on it being implemented the way it was. Given this was a 
useful interface, I think we should be more careful with it. I think it’s 
possible to bring backwards compatibility back by creating a wrapper class with 
the old interface. Would still require recompilation for the users, but could 
will make it painless to migrate.
 * Is there any reason we wouldn’t want to make the maps in 
{{TableMetadataRefCache}} immutable? I realise they can be sizeable, but in 
this case we could also hide them behind the interface, make default 
implementation immutable and let other implementations be more efficient if 
necessary. This way we can atomically swap/publish to all three maps.
 * I’m not sure about the name {{SharedSchema}} class and nomenclature:
 ** Class itself, if the whole point was to add a version to Keyspaces, maybe 
we should just add the version to Keyspaces, and make sure keyspaces are being 
updated synchronously with the version. Moreover, I think having version here 
and version left in {{SchemaManager}} is making it more confusing. I realise 
that you’ve tried to hide the version for {{SharedSchema}} in the Default 
handler, it’s unclear whose responsibility the version actually is.
 ** Nomenclature: I don’t think this schema is “shared” in any way: all 
keyspaces that aren’t local are just nonlocal, and a subset of them is just 
“userDefined”. Maybe we could use “replicated” or “distributed” instead of 
“nonlocal”.
 * Is there anything that justifies the existing of {{LocalKeyspaces}} class 
and prevents it from being just an instance of {{Keyspaces}} which is more 
functional but seems to be at least equivalent for its current usages?
 * {{reloadSchemaAndAnnounceVersion}} seems to pick all keyspaces and then 
filter out all system/local ones. Maybe we can just use “shared” (in 
nomenclature of your patch)
 * in {{SchemaDiagnostics}}, “schemata” doesn’t seem to be a typo, but rather a 
plural of “schema”. There are a few other mentions of schemata in this file, so 
I’d check it again.
 * Should we make a separate implementation of 
{{IEndpointStateChangeSubscriber}} within {{SchemaUpdateHandler}}, since
 * There seems to be an unintentional use of DSE 
[here|[https://github.com/apache/cassandra/pull/1270/commits/42a825a98fb4d2564508463911f43fd2754051d6#diff-fcad6f463c8c500997d27cceced47b8209088e21df328f8bc8f75507bc92b3eaR97]].
 I do not mind the presence of this method though even though it seems to be 
unused.
 * Nit: [CASSANDRA-17044: Refactor schema management by jacek-lewandowski · 
Pull Request #1270 · apache/cassandra · GitHub|#1270 · apache/cassandra · 
GitHub]([https://github.com/apache/cassandra/pull/1270/commits/42a825a98fb4d2564508463911f43fd2754051d6#diff-67531e8854562a763e98074cadaeee6d7c7c288a30ebef9fa465e249acab9fb2R115])
 here probably you have meant “local keyspace definitions” or something similar.
 * Unfortunately, I could not find a full set of passing tests accompanying the 
patch. Could you, when posting the updates, make sure to include a link to 
CircleCI?

Lastly, I feel like for a 4k lines of code patch, this one has surprisingly few 
tests. I realise that schema was always a generally undertested area of code, 
but I think our current quality standards do not allow us to do massive 
refactoring without substantial testing. Therefore, I suggest we create fuzz 
test that verifies schema eventual propagation, reads/writes during schema 
changes, and cross-node consistency of schema operations themselves, including 
concurrent ones. What seems to be particularly important to test is the gossip 
propagation of the version ID, which would lead to schema pulls, alongside with 
active schema pushes that is done when there’s a non-local schema change, and 
picking up schema during bootstrap.

Also, two comments about the scope of the patch, since the patch seems to have 
included several changes that seem to be unrelated to refactoring, and are 
rather bugfixes or performance improvements: 
 * 631fa2939708dd3cbd90f26442a7e167a3386cd7 is touching things that are used in 
almost every subsystem in the code. {{Keyspace.open()}} is a super common call. 
I think changes to such method deserves extensive testing, especially if 
previous code was inefficient but not problematic. If this is a performance 
improvement, I suggest to extract it and put it in a different patch, add tests 
and demonstrate the improvement. If

[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433657#comment-17433657
 ] 

Benedict Elliott Smith commented on CASSANDRA-17050:


That isn't related to this patch.

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433661#comment-17433661
 ] 

Benedict Elliott Smith commented on CASSANDRA-17050:


FWIW, the dependency check fails locally for unrelated reasons, seemingly 
unable to connect to nist.gov, though I am able to connect to nist.gov just 
fine and download the file it is looking for. So perhaps this check has some 
kinks to work out before we depend upon it. I'm also unconvinced of the sense 
of downloading an arbitrary binary direct from somebody's personal GitHub to 
execute on the local machine.

I'm not convinced of the sense of breaking builds that previously worked for 
this check, it should at most be a pre-release check rather than a pre-merge 
check. Perhaps it could also be pre-merge if build.xml modified as part of the 
patch.

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17055) Forbid other Future implementations with checkstyle

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433665#comment-17433665
 ] 

Benedict Elliott Smith commented on CASSANDRA-17055:


[Patch|https://github.com/belliottsmith/cassandra/tree/17055-trunk]


> Forbid other Future implementations with checkstyle
> ---
>
> Key: CASSANDRA-17055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17055
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17055) Forbid other Future implementations with checkstyle

2021-10-25 Thread Benedict Elliott Smith (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict Elliott Smith updated CASSANDRA-17055:
---
Test and Documentation Plan: n/a
 Status: Patch Available  (was: Open)

> Forbid other Future implementations with checkstyle
> ---
>
> Key: CASSANDRA-17055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17055
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17055) Forbid other Future implementations with checkstyle

2021-10-25 Thread Benedict Elliott Smith (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict Elliott Smith updated CASSANDRA-17055:
---
Change Category: Quality Assurance
 Complexity: Low Hanging Fruit
Component/s: Build
   Assignee: Benedict Elliott Smith
 Status: Open  (was: Triage Needed)

> Forbid other Future implementations with checkstyle
> ---
>
> Key: CASSANDRA-17055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17055
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-16413) Byteman fails to install injections after Jacoco upgrade

2021-10-25 Thread Jacek Lewandowski (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302446#comment-17302446
 ] 

Jacek Lewandowski edited comment on CASSANDRA-16413 at 10/25/21, 10:11 AM:
---

btw. to see the problem, you need to add {{org.jboss.byteman.verbose=true}} 
system property


was (Author: jlewandowski):
btw. to see the problem, you need to ass {{org.jboss.byteman.verbose=true}} 
system property

> Byteman fails to install injections after Jacoco upgrade
> 
>
> Key: CASSANDRA-16413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16413
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x
>
>
> This ticket is a follow up on CASSANDRA-16365 and it should be worked on 
> after the Jacoco upgrade is committed
> List of the failing tests:
> org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.testCompressedCommitLogBackpressure
> org.apache.cassandra.db.compaction.CompactionsBytemanTest.testSSTableNotEnoughDiskSpaceForCompactionGetsDropped
> org.apache.cassandra.db.compaction.CompactionsBytemanTest.testRuntimeExceptionWhenNoDiskSpaceForCompaction
> org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopUserDefinedCompactionRepaired
> org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopSubRangeCompactionRepaired
> org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
> org.apache.cassandra.gms.PendingRangeCalculatorServiceTest.testDelayedResponse
> org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Michael Semb Wever (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433670#comment-17433670
 ] 

Michael Semb Wever commented on CASSANDRA-17050:


That discussion (which is out of scope) is ongoing. 

pre-release check is no good, we want a faster feedback on such CVE breakages.

part of the problem is the check can fail for one of three reasons:
# a new dependency is introduced in the patch, and that should be caught (not 
merged)
# a new CVE is listed, and that breaks all our CI
# the nist.gov becomes unavailable, and that breaks all our CI.

We want (1) as part of CI. We want (2) as feedback as fast as possible, but not 
breaking CI. We want to ignore (workaround) (3).


> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17057) Refactor and support pluggable failure detection

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433675#comment-17433675
 ] 

Benedict Elliott Smith commented on CASSANDRA-17057:


There's already a config parameter to supply an {{IFailureDetector}}?

> Refactor and support pluggable failure detection
> 
>
> Key: CASSANDRA-17057
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17057
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matt Fleming
>Priority: Normal
>
> Making it possible to supply custom failure detectors enables supporting new 
> failure detection algorithms and makes testing using mocks much easier.
> The general idea is to introduce a new config parameter, such as 
> org.apache.cassandra.custom_failure_detector_class, that specifies the 
> failure detection class to use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433683#comment-17433683
 ] 

Benedict Elliott Smith commented on CASSANDRA-17044:


bq. Even though I generally like that SchemaChangeListener is now an interface 
rather than abstract class, I’m concerned about potential users who might have 
relied on it being implemented the way it was

My personal view on internal APIs like this is that we shouldn't offer any 
guarantees about backwards compatibility. In this instance if it's easy to 
maintain then great, but we should not set an expectation of this. The main 
goal should always be what is useful for Cassandra today. Just my 2¢.

> Refactor schema management to allow for schema source pluggability
> --
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for 
> different things. In particular extract what is related to schema storage and 
> synchronization into a separate class so that it is possible to create an 
> extension point there and store schema in a different way than 
> `system_schema` keyspace, for example in etcd. 
> This would also simplify the logic and reduce the number of special cases, 
> make all the things more testable and the logic of internal classes 
> encapsulated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17059) Support adding custom verbs at runtime

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433688#comment-17433688
 ] 

Benedict Elliott Smith commented on CASSANDRA-17059:


I look forward to seeing a patch, as it seems like it may harm the clarity of 
the codebase by forcing a migration away from {{Enum}} for {{Verb}}.

It would help to provide some concrete examples of the need for this feature, 
as this does not appear to enable improved testing or any specific feature for 
the project. If this is for an external use case, I think the ticket would 
benefit from a fuller description of the use case.

> Support adding custom verbs at runtime
> --
>
> Key: CASSANDRA-17059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17059
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matt Fleming
>Priority: Normal
>
> Cassandra already has support for registering custom verbs at build time, but 
> there's value in allowing verbs to be added at runtime since that enables new 
> use cases where it's inconvenient or impossible to modify the Cassandra 
> source.
> Additionally, apps that went to register new verbs benefit from running 
> custom code after the default verb handlers execute. This can be achieved 
> with straightforward modifications to the Sink interface (e.g. adding a 
> PostSink class).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17058) Refactor and support pluggable cluster membership

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433698#comment-17433698
 ] 

Benedict Elliott Smith commented on CASSANDRA-17058:


Just an FYI that this work might conflict with efforts to refactor membership 
more fully, where we might for instance remove the concept of a token ring.

> Refactor and support pluggable cluster membership
> -
>
> Key: CASSANDRA-17058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17058
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matt Fleming
>Priority: Normal
>
> Allowing users to specify a classes that implement a new 
> CustomTokenMetadataProvider class makes cluster membership pluggable 
> (supporting custom code) and makes testing much easier.
> Users could specify the cluster membership algorithm using a new config 
> parameter such as org.apache.cassandra.token_metadata_provider_class.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Jacek Lewandowski (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski reassigned CASSANDRA-15691:
-

Assignee: Jacek Lewandowski  (was: Michael Semb Wever)

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Jacek Lewandowski (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski updated CASSANDRA-15691:
--
Status: Review In Progress  (was: Patch Available)

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Jacek Lewandowski (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski updated CASSANDRA-15691:
--
Change Category: Code Clarity
 Complexity: Normal
  Reviewers: Michael Semb Wever
 Status: Open  (was: Triage Needed)

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Jacek Lewandowski (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski updated CASSANDRA-15691:
--
Test and Documentation Plan: -
 Status: Patch Available  (was: Open)

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Jacek Lewandowski (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Lewandowski updated CASSANDRA-15691:
--
Source Control Link: https://github.com/apache/cassandra-website/pull/79

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16917) Create property to hold local maven repository location

2021-10-25 Thread Michael Semb Wever (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433704#comment-17433704
 ] 

Michael Semb Wever commented on CASSANDRA-16917:


CI
- trunk 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1245/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1245/]
- 4.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1244/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1244/]
- 3.11 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1234/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1234/]
- 3.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1223/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1223/]

> Create property to hold local maven repository location
> ---
>
> Key: CASSANDRA-16917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16917
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> In their current state, both build.xml and .build/build-resolver.xml refer to 
> the local maven repository by "${user.home}/.m2/repository" in multiple 
> places.
> It would be nice instead to have a property store this location, and refer 
> the property vs the actual location itself. 
> If one needs to change this maven repository location for their environmental 
> purposes, this change makes it easy since it will need to be changed only at 
> one place (the value of the property) vs changing all the direct references 
> to the repository location.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Alex Petrov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433708#comment-17433708
 ] 

Alex Petrov commented on CASSANDRA-17044:
-

[~benedict] you're right. My thinking was that since it's a Listener, there 
might be implementations outside the codebase, but I agree we should always 
move towards what's most useful for Cassandra today. This, then, also applies 
to the API introduced in this patch: if changes introducing consistent schema 
require changes in this API, we will have to make changes to it.

> Refactor schema management to allow for schema source pluggability
> --
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for 
> different things. In particular extract what is related to schema storage and 
> synchronization into a separate class so that it is possible to create an 
> extension point there and store schema in a different way than 
> `system_schema` keyspace, for example in etcd. 
> This would also simplify the logic and reduce the number of special cases, 
> make all the things more testable and the logic of internal classes 
> encapsulated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Alex Petrov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433642#comment-17433642
 ] 

Alex Petrov edited comment on CASSANDRA-17044 at 10/25/21, 11:55 AM:
-

Thank you for the patch and clarifications. I like the overall direction 
towards modularisation and interfaces. My comments are following.
 * Even though I generally like that {{SchemaChangeListener}} is now an 
interface rather than abstract class, I’m concerned about potential users who 
might have relied on it being implemented the way it was. Given this was a 
useful interface, I think we should be more careful with it. I think it’s 
possible to bring backwards compatibility back by creating a wrapper class with 
the old interface. Would still require recompilation for the users, but could 
will make it painless to migrate.
 * Is there any reason we wouldn’t want to make the maps in 
{{TableMetadataRefCache}} immutable? I realise they can be sizeable, but in 
this case we could also hide them behind the interface, make default 
implementation immutable and let other implementations be more efficient if 
necessary. This way we can atomically swap/publish to all three maps.
 * I’m not sure about the name {{SharedSchema}} class and nomenclature:
 ** Class itself, if the whole point was to add a version to Keyspaces, maybe 
we should just add the version to Keyspaces, and make sure keyspaces are being 
updated synchronously with the version. Moreover, I think having version here 
and version left in {{SchemaManager}} is making it more confusing. I realise 
that you’ve tried to hide the version for {{SharedSchema}} in the Default 
handler, it’s unclear whose responsibility the version actually is.
 ** Nomenclature: I don’t think this schema is “shared” in any way: all 
keyspaces that aren’t local are just nonlocal, and a subset of them is just 
“userDefined”. Maybe we could use “replicated” or “distributed” instead of 
“nonlocal”.
 * Is there anything that justifies the existing of {{LocalKeyspaces}} class 
and prevents it from being just an instance of {{Keyspaces}} which is more 
functional but seems to be at least equivalent for its current usages?
 * {{reloadSchemaAndAnnounceVersion}} seems to pick all keyspaces and then 
filter out all system/local ones. Maybe we can just use “shared” (in 
nomenclature of your patch)
 * in {{SchemaDiagnostics}}, “schemata” doesn’t seem to be a typo, but rather a 
plural of “schema”. There are a few other mentions of schemata in this file, so 
I’d check it again.
 * Should we make a separate implementation of 
{{IEndpointStateChangeSubscriber}} within {{SchemaUpdateHandler}}, since
 * There seems to be an unintentional use of DSE 
[here|https://github.com/apache/cassandra/pull/1270/commits/42a825a98fb4d2564508463911f43fd2754051d6#diff-fcad6f463c8c500997d27cceced47b8209088e21df328f8bc8f75507bc92b3eaR97].
 I do not mind the presence of this method though even though it seems to be 
unused.
 * Nit: 
[here|https://github.com/apache/cassandra/pull/1270/commits/42a825a98fb4d2564508463911f43fd2754051d6#diff-67531e8854562a763e98074cadaeee6d7c7c288a30ebef9fa465e249acab9fb2R115]
 probably you have meant “local keyspace definitions” or something similar.
 * Unfortunately, I could not find a full set of passing tests accompanying the 
patch. Could you, when posting the updates, make sure to include a link to 
CircleCI?

Lastly, I feel like for a 4k lines of code patch, this one has surprisingly few 
tests. I realise that schema was always a generally undertested area of code, 
but I think our current quality standards do not allow us to do massive 
refactoring without substantial testing. Therefore, I suggest we create fuzz 
test that verifies schema eventual propagation, reads/writes during schema 
changes, and cross-node consistency of schema operations themselves, including 
concurrent ones. What seems to be particularly important to test is the gossip 
propagation of the version ID, which would lead to schema pulls, alongside with 
active schema pushes that is done when there’s a non-local schema change, and 
picking up schema during bootstrap.

Also, two comments about the scope of the patch, since the patch seems to have 
included several changes that seem to be unrelated to refactoring, and are 
rather bugfixes or performance improvements: 
 * 631fa2939708dd3cbd90f26442a7e167a3386cd7 is touching things that are used in 
almost every subsystem in the code. {{Keyspace.open()}} is a super common call. 
I think changes to such method deserves extensive testing, especially if 
previous code was inefficient but not problematic. If this is a performance 
improvement, I suggest to extract it and put it in a different patch, add tests 
and demonstrate the improvement. If it’s a bug - I'd report it as such as well
 * 424cf4ae9544b33a617b6a1a95aee6aad47a98ec I think als

[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Jacek Lewandowski (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433716#comment-17433716
 ] 

Jacek Lewandowski commented on CASSANDRA-17044:
---

Thank you [~ifesdjeen], I really appreciate such a fast review. I'll be 
responding to your points shortly. 

Just regarding the APIs - perhaps some idea for the future would be to start 
explicitly marking which interfaces/classes are {{@DeveloperAPI}}? I saw this 
approach in Spark project. Such classes had some guarantees about not being 
changed for certain versions range.

> Refactor schema management to allow for schema source pluggability
> --
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for 
> different things. In particular extract what is related to schema storage and 
> synchronization into a separate class so that it is possible to create an 
> extension point there and store schema in a different way than 
> `system_schema` keyspace, for example in etcd. 
> This would also simplify the logic and reduce the number of special cases, 
> make all the things more testable and the logic of internal classes 
> encapsulated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433719#comment-17433719
 ] 

Benedict Elliott Smith commented on CASSANDRA-17044:


I think APIs fall into two buckets: internal and external. 

I can't imagine a reason why internal APIs should need annotating, as they 
should offer no guarantees at all to any user that exploits them, they simply 
provide utility for structuring or testing the code. AFAICT this refactor falls 
into this bucket. 

External APIs should have some explicit consideration for compatibility, even 
if it is minimal it should have a well defined and documented approach with 
what the user can expect. External APIs obviously have to clear much greater 
hurdles for introduction to the codebase given the restrictions they place on 
future development, and I'd be pretty opposed to that in this instance.

> Refactor schema management to allow for schema source pluggability
> --
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for 
> different things. In particular extract what is related to schema storage and 
> synchronization into a separate class so that it is possible to create an 
> extension point there and store schema in a different way than 
> `system_schema` keyspace, for example in etcd. 
> This would also simplify the logic and reduce the number of special cases, 
> make all the things more testable and the logic of internal classes 
> encapsulated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability

2021-10-25 Thread Alex Petrov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433720#comment-17433720
 ] 

Alex Petrov commented on CASSANDRA-17044:
-

I'd say, for the APIs where we expect significant changes, I'd say we should 
not (and can not, really) make any guarantees whatsoever. For some of the APIs 
(for which seems to be some discussion on ML), we should have at least some 
stability. That said, say, if we have a 2i API, since our main goal as Apache 
project is to maintain 2i implementations in-tree (be it SASI or, potentially, 
SAI), if someone were to come and make a change, but at the same time adjust 
the in-tree SASI and SAI implementations accordingly, I'd say we should allow 
such a change. Maintainers of external indexes will have to adjust. What I 
haven't considered when writing my previous comment is if we'll allow external 
code to dictate what's good for the project, we may not be able to deliver the 
changes in the best possible way.

> Refactor schema management to allow for schema source pluggability
> --
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for 
> different things. In particular extract what is related to schema storage and 
> synchronization into a separate class so that it is possible to create an 
> extension point there and store schema in a different way than 
> `system_schema` keyspace, for example in etcd. 
> This would also simplify the logic and reduce the number of special cases, 
> make all the things more testable and the logic of internal classes 
> encapsulated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Michael Semb Wever (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433721#comment-17433721
 ] 

Michael Semb Wever commented on CASSANDRA-17050:


CI
- trunk 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1243/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1243/]
- 4.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1241/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1241/]
- 3.11 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1240/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1240/]
- 3.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1239/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1239/]
- 2.2 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1238/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1238/]

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Michael Semb Wever (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-17050:
---
Reviewers: Michael Semb Wever, Michael Semb Wever  (was: Michael Semb Wever)
   Michael Semb Wever, Michael Semb Wever
   Status: Review In Progress  (was: Patch Available)

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17050) Upgrade tests fail with InvocationTargetException

2021-10-25 Thread Benedict Elliott Smith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433726#comment-17433726
 ] 

Benedict Elliott Smith commented on CASSANDRA-17050:


It looks like there's another [unrelated 
issue|https://app.circleci.com/pipelines/github/belliottsmith/cassandra/113/workflows/1f672000-5432-44d7-a691-b1d397c40932/jobs/3866/tests#failed-test-5]

This might require an update to dtest-api, I'm investigating

> Upgrade tests fail with InvocationTargetException
> -
>
> Key: CASSANDRA-17050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17050
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Urgent
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Upgrade tests are currently failing due to the new dtest-api changes and 
> their integration with trunk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-17064) dtest-api: Option to start nodes with blank gossip state

2021-10-25 Thread Benedict Elliott Smith (Jira)
Benedict Elliott Smith created CASSANDRA-17064:
--

 Summary: dtest-api: Option to start nodes with blank gossip state
 Key: CASSANDRA-17064
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17064
 Project: Cassandra
  Issue Type: Improvement
  Components: Test/dtest/java
Reporter: Benedict Elliott Smith
Assignee: Benedict Elliott Smith


dtest-api should permit starting nodes with neither regular gossip nor 
artificially injected gossip, so that the Gossip state may be modified by the 
tests from a blank slate



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14160) maxPurgeableTimestamp should traverse tables in order of minTimestamp

2021-10-25 Thread Brandon Williams (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433739#comment-17433739
 ] 

Brandon Williams commented on CASSANDRA-14160:
--

I believe it is still valid, [~subkanthi]

> maxPurgeableTimestamp should traverse tables in order of minTimestamp
> -
>
> Key: CASSANDRA-14160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14160
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Josh Snyder
>Priority: Normal
>  Labels: performance
> Fix For: 4.x
>
>
> In maxPurgeableTimestamp, we iterate over the bloom filters of each 
> overlapping SSTable. Of the bloom filter hits, we take the SSTable with the 
> lowest minTimestamp. If we kept the SSTables in sorted order of minTimestamp, 
> then we could short-circuit the operation at the first bloom filter hit, 
> reducing cache pressure (or worse, I/O) and CPU time.
> I've written (but not yet benchmarked) [some 
> code|https://github.com/hashbrowncipher/cassandra/commit/29859a4a2e617f6775be49448858bc59fdafab44]
>  to demonstrate this possibility.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Ekaterina Dimitrova (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433768#comment-17433768
 ] 

Ekaterina Dimitrova commented on CASSANDRA-15691:
-

Hey [~jlewandowski],

I just saw you assigned this ticket and I wasn't sure whether you follow the ML 
thread discussions or if you have spoken to [~mck] or [~polandll].

On one side there is work that it is supposed to be committed soon and then we 
can update documents in asciidoc.

On the other hand further to the testing page I am working on the side to 
update our wiki for CircleCI usage but the work is pending on the asciidoc as I 
have to convert from rst a few CircleCI related docs and then correct the links 
in the wiki before releasing.

Hope this info helps. Please let me know if you have any questions or I can 
help with anything.

 

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17054) v4+ protocol does not clean up client warnings, which causes leaking the state

2021-10-25 Thread Jon Meredith (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433771#comment-17433771
 ] 

Jon Meredith commented on CASSANDRA-17054:
--

+1

> v4+ protocol does not clean up client warnings, which causes leaking the state
> --
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17054) v4+ protocol does not clean up client warnings, which causes leaking the state

2021-10-25 Thread David Capwell (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Capwell updated CASSANDRA-17054:
--
Status: Ready to Commit  (was: Review In Progress)

> v4+ protocol does not clean up client warnings, which causes leaking the state
> --
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17054) v4+ protocol did not clean up client warnings, which caused leaking the state

2021-10-25 Thread David Capwell (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Capwell updated CASSANDRA-17054:
--
Summary: v4+ protocol did not clean up client warnings, which caused 
leaking the state  (was: v4+ protocol does not clean up client warnings, which 
causes leaking the state)

> v4+ protocol did not clean up client warnings, which caused leaking the state
> -
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch trunk updated: Remove duplicate toCQLString in ReadCommand

2021-10-25 Thread brandonwilliams
This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 60e0da1  Remove duplicate toCQLString in ReadCommand
60e0da1 is described below

commit 60e0da1bd0f8271f7bbba300695d67b9ad0a497f
Author: Kanthi Subramanian 
AuthorDate: Fri Oct 22 11:55:23 2021 -0400

Remove duplicate toCQLString in ReadCommand

Patch by Kanthi Subramanian; reviewed by brandonwilliams and maedhroz
for CASSANDRA-17023
---
 CHANGES.txt|  1 +
 src/java/org/apache/cassandra/db/ReadCommand.java  | 30 --
 .../org/apache/cassandra/db/ReadCommandTest.java   | 13 ++
 3 files changed, 14 insertions(+), 30 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 3208ff8..68aeb04 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.1
+ * Remove duplicate toCQLString in ReadCommand (CASSANDRA-17023)
  * Ensure hint window is persistent across restarts of a node (CASSANDRA-14309)
  * Allow to GRANT or REVOKE multiple permissions in a single statement 
(CASSANDRA-17030)
  * Allow to grant permission for all tables in a keyspace (CASSANDRA-17027)
diff --git a/src/java/org/apache/cassandra/db/ReadCommand.java 
b/src/java/org/apache/cassandra/db/ReadCommand.java
index fd4636e..f14240b 100644
--- a/src/java/org/apache/cassandra/db/ReadCommand.java
+++ b/src/java/org/apache/cassandra/db/ReadCommand.java
@@ -35,7 +35,6 @@ import org.slf4j.LoggerFactory;
 
 import io.netty.util.concurrent.FastThreadLocal;
 import org.apache.cassandra.config.*;
-import org.apache.cassandra.cql3.ColumnIdentifier;
 import org.apache.cassandra.db.filter.*;
 import org.apache.cassandra.net.MessageFlag;
 import org.apache.cassandra.net.ParamType;
@@ -782,35 +781,6 @@ public abstract class ReadCommand extends AbstractReadQuery
 }
 
 /**
- * Recreate the CQL string corresponding to this query.
- * 
- * Note that in general the returned string will not be exactly the 
original user string, first
- * because there isn't always a single syntax for a given query,  but also 
because we don't have
- * all the information needed (we know the non-PK columns queried but not 
the PK ones as internally
- * we query them all). So this shouldn't be relied too strongly, but this 
should be good enough for
- * debugging purpose which is what this is for.
- */
-public String toCQLString()
-{
-StringBuilder sb = new StringBuilder().append("SELECT ")
-  
.append(columnFilter().toCQLString())
-  .append(" FROM ")
-  
.append(ColumnIdentifier.maybeQuote(metadata().keyspace))
-  .append('.')
-  
.append(ColumnIdentifier.maybeQuote(metadata().name));
-
-appendCQLWhereClause(sb);
-
-if (limits() != DataLimits.NONE)
-sb.append(' ').append(limits());
-
-// ALLOW FILTERING might not be strictly necessary
-sb.append(" ALLOW FILTERING");
-
-return sb.toString();
-}
-
-/**
  * Return the queried token(s) for logging
  */
 public abstract String loggableTokens();
diff --git a/test/unit/org/apache/cassandra/db/ReadCommandTest.java 
b/test/unit/org/apache/cassandra/db/ReadCommandTest.java
index 52a92b4..69b8c37 100644
--- a/test/unit/org/apache/cassandra/db/ReadCommandTest.java
+++ b/test/unit/org/apache/cassandra/db/ReadCommandTest.java
@@ -1191,6 +1191,19 @@ public class ReadCommandTest

ReplicaUtils.full(addr, token)));
 }
 
+@Test
+public void testToCQLString()
+{
+ColumnFamilyStore cfs = 
Keyspace.open(KEYSPACE).getColumnFamilyStore(CF2);
+DecoratedKey key = Util.dk("key");
+
+ReadCommand readCommand = Util.cmd(cfs, key).build();
+
+String result = readCommand.toCQLString();
+
+assertEquals(result, String.format("SELECT * FROM 
\"ReadCommandTest\".\"Standard2\" WHERE key = 0x%s ALLOW FILTERING", 
ByteBufferUtil.bytesToHex(key.getKey(;
+}
+
 private void testRepairedDataTracking(ColumnFamilyStore cfs, ReadCommand 
readCommand)
 {
 cfs.truncateBlocking();

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17023) Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery

2021-10-25 Thread Brandon Williams (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-17023:
-
Source Control Link: 
https://github.com/apache/cassandra/commit/60e0da1bd0f8271f7bbba300695d67b9ad0a497f
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed, thank you.

> Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
> -
>
> Key: CASSANDRA-17023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17023
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This is certainly low-hanging fruit, but the {{toCQLString()}} in 
> {{ReadCommand}} now entirely duplicates the one in its superclass 
> {{AbstractReadQuery}}. I think we can just remove the former.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16945) Multiple full sources can be select unexpectedly for bootstrap streaming

2021-10-25 Thread Brandon Williams (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16945:
-
Reviewers: Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Status: Review In Progress  (was: Patch Available)

>  Multiple full sources can be select unexpectedly for bootstrap streaming
> -
>
> Key: CASSANDRA-16945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16945
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Bootstrap and Decommission
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> With CASSANDRA-14404, the RangeStreamer selects all endpoints as sources when 
> using strict consistency and RF > endpoints count. In such case, the 
> bootstrapping node is almost guaranteed to fail in the validation later. 
> It is a change of behavior. Before the patch, in such case (i.e., higher RF) 
> the bootstrapping node just pick one endpoint as source, since consistent 
> range movement cannot be established. I'd propose to restore the old behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16945) Multiple full sources can be select unexpectedly for bootstrap streaming

2021-10-25 Thread Brandon Williams (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16945:
-
Status: Ready to Commit  (was: Review In Progress)

>  Multiple full sources can be select unexpectedly for bootstrap streaming
> -
>
> Key: CASSANDRA-16945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16945
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Bootstrap and Decommission
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> With CASSANDRA-14404, the RangeStreamer selects all endpoints as sources when 
> using strict consistency and RF > endpoints count. In such case, the 
> bootstrapping node is almost guaranteed to fail in the validation later. 
> It is a change of behavior. Before the patch, in such case (i.e., higher RF) 
> the bootstrapping node just pick one endpoint as source, since consistent 
> range movement cannot be established. I'd propose to restore the old behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17054) v4+ protocol did not clean up client warnings, which caused leaking the state

2021-10-25 Thread David Capwell (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433796#comment-17433796
 ] 

David Capwell commented on CASSANDRA-17054:
---

Starting commit

CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17054-trunk-D0BB41D6-69AC-42C7-B884-2B22CE33E742]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17054-trunk-D0BB41D6-69AC-42C7-B884-2B22CE33E742]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1247/]|


> v4+ protocol did not clean up client warnings, which caused leaking the state
> -
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters

2021-10-25 Thread Ekaterina Dimitrova (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433798#comment-17433798
 ] 

Ekaterina Dimitrova commented on CASSANDRA-15234:
-

For the record, this is the discussion thread from the dev mailing list - 
[https://lists.apache.org/thread.html/r507be1624a568765f9d5ec5f6b561885129d0aaeb982e9bd9bf5e01b%40%3Cdev.cassandra.apache.org%3E]

Based on it, I am getting back to this work.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Michael Semb Wever (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433800#comment-17433800
 ] 

Michael Semb Wever commented on CASSANDRA-15691:


bq. On one side there is work that it is supposed to be committed soon and then 
we can update documents in asciidoc.

[~jlewandowski] is working on a 
[PR|https://github.com/apache/cassandra-website/pull/79] that only touches the 
cassandra-website repo, so isn't blocked on CASSANDRA-16763.

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org

2021-10-25 Thread Ekaterina Dimitrova (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433807#comment-17433807
 ] 

Ekaterina Dimitrova commented on CASSANDRA-15691:
-

Ok, thank you [~mck]

> DOC - Review Testing section, update builds info to ci-cassandra.apache.org
> ---
>
> Key: CASSANDRA-15691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15691
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> h2. Background
> While discussing doc updates to CASSANDRA-15466 on [ASF 
> Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I 
> discovered that the 
> [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] 
> page requires a review.
> h2. Sample section
> [~mck] advised that the linked CI server here:
> bq. Using dtests helps us to prevent regression bugs by continually executing 
> tests on the [CI server|https://builds.apache.org/] against new patches.
> should be https://ci-cassandra.apache.org/.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14113) AssertionError while trying to upgrade 2.2.11 -> 3.11.1

2021-10-25 Thread Benjamin Lerer (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-14113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433822#comment-17433822
 ] 

Benjamin Lerer commented on CASSANDRA-14113:


[~knbk] Sorry for the long delay.
Your proposal make sense to me as a super column is considered as sparse if it 
has some {{column_metadata}}.
Would you be interested in providing a patch for this ticket? 

> AssertionError while trying to upgrade 2.2.11 -> 3.11.1
> ---
>
> Key: CASSANDRA-14113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14113
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
> Environment: Tables have been created in 2.2.11 using thrift and have 
> supercolumns
>Reporter: Guillaume Herail
>Assignee: Benjamin Lerer
>Priority: Normal
>  Labels: supercolumns
> Attachments: data.tar.gz
>
>
> We're trying to upgrade a test cluster from Cassandra 2.2.11 to Cassandra 
> 3.11.1. The tables have been created using thrift and have supercolumns. When 
> I try to run {{nodetool upgradesstables}} I get the following:
> {noformat}error: null
> -- StackTrace --
> java.lang.AssertionError
>   at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:42)
>   at 
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242)
>   at 
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185)
>   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:498)
>   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472)
>   at 
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306)
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:188)
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:140)
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
>   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:122)
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
>   at 
> org.apache.cassandra.utils.MergeIterator$TrivialOneToOne.computeNext(MergeIterator.java:484)
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
>   at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
>   at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
>   at 
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:75)
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
>   at 
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDealloc

[cassandra-diff] branch trunk updated: Probabilistic diff to sample partitions for diff testing based on probability

2021-10-25 Thread ycai
This is an automated email from the ASF dual-hosted git repository.

ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-diff.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 0e0d08b  Probabilistic diff to sample partitions for diff testing 
based on probability
0e0d08b is described below

commit 0e0d08be0f6ad70e97c55cf35b9eae16171c9eac
Author: Jyothsna Konisa 
AuthorDate: Thu Sep 23 12:47:38 2021 -0700

Probabilistic diff to sample partitions for diff testing based on 
probability

Patch by Jyothsna Konisa; reviewed by Dinesh Joshi, Yifan Cai for 
CASSANDRA-16967
---
 .../apache/cassandra/diff/JobConfiguration.java|  7 
 .../cassandra/diff/YamlJobConfiguration.java   |  7 
 .../java/org/apache/cassandra/diff/Differ.java | 24 ++-
 .../org/apache/cassandra/diff/RangeComparator.java | 32 +++---
 .../org/apache/cassandra/diff/DiffJobTest.java |  5 +++
 .../java/org/apache/cassandra/diff/DifferTest.java | 49 ++
 .../apache/cassandra/diff/RangeComparatorTest.java | 32 ++
 .../java/org/apache/cassandra/diff/SchemaTest.java |  5 +++
 8 files changed, 154 insertions(+), 7 deletions(-)

diff --git 
a/common/src/main/java/org/apache/cassandra/diff/JobConfiguration.java 
b/common/src/main/java/org/apache/cassandra/diff/JobConfiguration.java
index 7a20b30..8d74de8 100644
--- a/common/src/main/java/org/apache/cassandra/diff/JobConfiguration.java
+++ b/common/src/main/java/org/apache/cassandra/diff/JobConfiguration.java
@@ -88,6 +88,13 @@ public interface JobConfiguration extends Serializable {
 MetadataKeyspaceOptions metadataOptions();
 
 /**
+ * Sampling probability ranges from 0-1 which decides how many partitions 
are to be diffed using probabilistic diff
+ * default value is 1 which means all the partitions are diffed
+ * @return partitionSamplingProbability
+ */
+double partitionSamplingProbability();
+
+/**
  * Contains the options that specify the retry strategy for retrieving 
data at the application level.
  * Note that it is different than cassandra java driver's {@link 
com.datastax.driver.core.policies.RetryPolicy},
  * which is evaluated at the Netty worker threads.
diff --git 
a/common/src/main/java/org/apache/cassandra/diff/YamlJobConfiguration.java 
b/common/src/main/java/org/apache/cassandra/diff/YamlJobConfiguration.java
index 359466a..7d60403 100644
--- a/common/src/main/java/org/apache/cassandra/diff/YamlJobConfiguration.java
+++ b/common/src/main/java/org/apache/cassandra/diff/YamlJobConfiguration.java
@@ -48,6 +48,7 @@ public class YamlJobConfiguration implements JobConfiguration 
{
 public String specific_tokens = null;
 public String disallowed_tokens = null;
 public RetryOptions retry_options;
+public double partition_sampling_probability = 1;
 
 public static YamlJobConfiguration load(InputStream inputStream) {
 Yaml yaml = new Yaml(new 
CustomClassLoaderConstructor(YamlJobConfiguration.class,
@@ -103,6 +104,11 @@ public class YamlJobConfiguration implements 
JobConfiguration {
 return metadata_options;
 }
 
+@Override
+public double partitionSamplingProbability() {
+return partition_sampling_probability;
+}
+
 public RetryOptions retryOptions() {
 return retry_options;
 }
@@ -130,6 +136,7 @@ public class YamlJobConfiguration implements 
JobConfiguration {
", keyspace_tables=" + keyspace_tables +
", buckets=" + buckets +
", rate_limit=" + rate_limit +
+   ", partition_sampling_probability=" + 
partition_sampling_probability +
", job_id='" + job_id + '\'' +
", token_scan_fetch_size=" + token_scan_fetch_size +
", partition_read_fetch_size=" + partition_read_fetch_size +
diff --git a/spark-job/src/main/java/org/apache/cassandra/diff/Differ.java 
b/spark-job/src/main/java/org/apache/cassandra/diff/Differ.java
index cf1c9a5..11794c5 100644
--- a/spark-job/src/main/java/org/apache/cassandra/diff/Differ.java
+++ b/spark-job/src/main/java/org/apache/cassandra/diff/Differ.java
@@ -27,10 +27,12 @@ import java.util.HashMap;
 import java.util.Iterator;
 import java.util.List;
 import java.util.Map;
+import java.util.Random;
 import java.util.UUID;
 import java.util.concurrent.Callable;
 import java.util.function.BiConsumer;
 import java.util.function.Function;
+import java.util.function.Predicate;
 import java.util.stream.Collectors;
 
 import com.google.common.annotations.VisibleForTesting;
@@ -63,6 +65,7 @@ public class Differ implements Serializable
 private final double reverseReadProbability;
 private final SpecificTokens specificTokens;
 private final RetryStrategyProvider retryStrategyProvider;
+private final double partitionSamplingProbability;
 
 private static DiffCluster srcDiffCluster;
  

[cassandra] branch trunk updated: v4+ protocol did not clean up client warnings, which caused leaking the state

2021-10-25 Thread dcapwell
This is an automated email from the ASF dual-hosted git repository.

dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 8e225c5  v4+ protocol did not clean up client warnings, which caused 
leaking the state
8e225c5 is described below

commit 8e225c55c49493f00fc9bc0b5809ab026d60c767
Author: David Capwell 
AuthorDate: Mon Oct 25 07:28:08 2021 -0700

v4+ protocol did not clean up client warnings, which caused leaking the 
state

patch by David Capwell; reviewed by Caleb Rackliffe, Jon Meredith, Sam 
Tunnicliffe for CASSANDRA-17054
---
 CHANGES.txt|  1 +
 .../org/apache/cassandra/transport/Dispatcher.java | 38 -
 .../transport/InitialConnectionHandler.java|  2 +-
 .../org/apache/cassandra/transport/Message.java| 11 ++-
 .../distributed/test/JavaDriverUtils.java  |  9 +++
 .../distributed/test/NativeMixedVersionTest.java   | 89 ++
 6 files changed, 130 insertions(+), 20 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 68aeb04..8ef8531 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.1
+ * v4+ protocol did not clean up client warnings, which caused leaking the 
state (CASSANDRA-17054)
  * Remove duplicate toCQLString in ReadCommand (CASSANDRA-17023)
  * Ensure hint window is persistent across restarts of a node (CASSANDRA-14309)
  * Allow to GRANT or REVOKE multiple permissions in a single statement 
(CASSANDRA-17030)
diff --git a/src/java/org/apache/cassandra/transport/Dispatcher.java 
b/src/java/org/apache/cassandra/transport/Dispatcher.java
index 31b750e..3aff2d2 100644
--- a/src/java/org/apache/cassandra/transport/Dispatcher.java
+++ b/src/java/org/apache/cassandra/transport/Dispatcher.java
@@ -82,9 +82,10 @@ public class Dispatcher
 }
 
 /**
- * Note: this method may be executed on the netty event loop, during 
initial protocol negotiation
+ * Note: this method may be executed on the netty event loop, during 
initial protocol negotiation; the caller is
+ * responsible for cleaning up any global or thread-local state. (ex. 
tracing, client warnings, etc.).
  */
-static Message.Response processRequest(ServerConnection connection, 
Message.Request request, Overload backpressure)
+private static Message.Response processRequest(ServerConnection 
connection, Message.Request request, Overload backpressure)
 {
 long queryStartNanoTime = nanoTime();
 if (connection.getVersion().isGreaterOrEqualTo(ProtocolVersion.V4))
@@ -99,7 +100,7 @@ public class Dispatcher
 {
 String message = String.format("Request breached global limit of 
%d requests/second and triggered backpressure.",

ClientResourceLimits.getNativeTransportMaxRequestsPerSecond());
-
+
 NoSpamLogger.log(logger, NoSpamLogger.Level.INFO, 1, 
TimeUnit.MINUTES, message);
 ClientWarn.instance.warn(message);
 }
@@ -107,7 +108,7 @@ public class Dispatcher
 {
 String message = String.format("Request breached limit(s) on bytes 
in flight (Endpoint: %d, Global: %d) and triggered backpressure.",

ClientResourceLimits.getEndpointLimit(), ClientResourceLimits.getGlobalLimit());
-
+
 NoSpamLogger.log(logger, NoSpamLogger.Level.INFO, 1, 
TimeUnit.MINUTES, message);
 ClientWarn.instance.warn(message);
 }
@@ -129,39 +130,42 @@ public class Dispatcher
 }
 
 /**
- * Note: this method is not expected to execute on the netty event loop.
+ * Note: this method may be executed on the netty event loop.
  */
-void processRequest(Channel channel, Message.Request request, 
FlushItemConverter forFlusher, Overload backpressure)
+static Message.Response processRequest(Channel channel, Message.Request 
request, Overload backpressure)
 {
-final Message.Response response;
-final ServerConnection connection;
-FlushItem toFlush;
 try
 {
-assert request.connection() instanceof ServerConnection;
-connection = (ServerConnection) request.connection();
-response = processRequest(connection, request, backpressure);
-toFlush = forFlusher.toFlushItem(channel, request, response);
-Message.logger.trace("Responding: {}, v={}", response, 
connection.getVersion());
+return processRequest((ServerConnection) request.connection(), 
request, backpressure);
 }
 catch (Throwable t)
 {
 JVMStabilityInspector.inspectThrowable(t);
-
+
 if (request.isTrackable())
 CoordinatorWarnings.done();
-
+
 Predicate handler = 
ExceptionHandlers.getUnexpectedExceptionHand

[jira] [Commented] (CASSANDRA-17054) v4+ protocol did not clean up client warnings, which caused leaking the state

2021-10-25 Thread David Capwell (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433833#comment-17433833
 ] 

David Capwell commented on CASSANDRA-17054:
---

a lot of tests are failing, but they are also failing on trunk (reported in 
slack as well), so merging even though there are many test failures...

> v4+ protocol did not clean up client warnings, which caused leaking the state
> -
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17054) v4+ protocol did not clean up client warnings, which caused leaking the state

2021-10-25 Thread David Capwell (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Capwell updated CASSANDRA-17054:
--
  Fix Version/s: (was: 4.0.x)
 (was: 4.x)
 4.1
  Since Version: 4.0.0
Source Control Link: 
https://github.com/apache/cassandra/commit/d8fff9b2d0e79fa8d945a8cdc1295fda3deae77c
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> v4+ protocol did not clean up client warnings, which caused leaking the state
> -
>
> Key: CASSANDRA-17054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1
>
>
> If you perform a query in v5, this will cause the STARTUP message to be 
> handled in the netty thread, but the way this is done is by calling an 
> internal API to dispatcher which requires the caller to clean up; but we do 
> not clean up; at this point the netty thread will have a ClientWarn state 
> populated.  If you now perform the same query again, but with the v3 
> protocol, this will pick up the state and try to serialize it, causing a 
> client error (in java as java rejects the output from the server) saying that 
> v3 may not have client warnings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-10-25 Thread Yifan Cai (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yifan Cai updated CASSANDRA-16967:
--
  Fix Version/s: cassandra-diff-0.2
Source Control Link: 
https://github.com/apache/cassandra-diff/commit/0e0d08be0f6ad70e97c55cf35b9eae16171c9eac
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed into trunk as 
[0e0d08b|https://github.com/apache/cassandra-diff/commit/0e0d08be0f6ad70e97c55cf35b9eae16171c9eac]

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Fix For: cassandra-diff-0.2
>
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Caleb Rackliffe (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433847#comment-17433847
 ] 

Caleb Rackliffe commented on CASSANDRA-16996:
-

CASSANDRA-17050 will make it noisy unfortunately, but +1 if we don't make it 
worse.

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0, 4.x
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-17065) Introduce separate rate limiting settings for entire SSTable streaming

2021-10-25 Thread Francisco Guerrero (Jira)
Francisco Guerrero created CASSANDRA-17065:
--

 Summary: Introduce separate rate limiting settings for entire 
SSTable streaming
 Key: CASSANDRA-17065
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17065
 Project: Cassandra
  Issue Type: Improvement
  Components: Messaging/Internode, Tool/nodetool
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero


With the introduction of entire SSTable streaming, it is desirable to introduce 
new settings for the rate limit for entire SSTable streaming operations.

Currently, regular streaming and SSTable streaming are rate limited by the same 
setting. However, zero-copy streaming reduces load in the JVM and we can have a 
setting specifically for this use case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-17065) Introduce separate rate limiting settings for entire SSTable streaming

2021-10-25 Thread Francisco Guerrero (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Guerrero updated CASSANDRA-17065:
---
Reviewers: Dinesh Joshi, Marcus Eriksson

> Introduce separate rate limiting settings for entire SSTable streaming
> --
>
> Key: CASSANDRA-17065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17065
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode, Tool/nodetool
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the introduction of entire SSTable streaming, it is desirable to 
> introduce new settings for the rate limit for entire SSTable streaming 
> operations.
> Currently, regular streaming and SSTable streaming are rate limited by the 
> same setting. However, zero-copy streaming reduces load in the JVM and we can 
> have a setting specifically for this use case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17065) Introduce separate rate limiting settings for entire SSTable streaming

2021-10-25 Thread Francisco Guerrero (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433987#comment-17433987
 ] 

Francisco Guerrero commented on CASSANDRA-17065:


PR: https://github.com/apache/cassandra/pull/1289

> Introduce separate rate limiting settings for entire SSTable streaming
> --
>
> Key: CASSANDRA-17065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17065
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode, Tool/nodetool
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the introduction of entire SSTable streaming, it is desirable to 
> introduce new settings for the rate limit for entire SSTable streaming 
> operations.
> Currently, regular streaming and SSTable streaming are rate limited by the 
> same setting. However, zero-copy streaming reduces load in the JVM and we can 
> have a setting specifically for this use case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-17065) Introduce separate rate limiting settings for entire SSTable streaming

2021-10-25 Thread Francisco Guerrero (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434039#comment-17434039
 ] 

Francisco Guerrero commented on CASSANDRA-17065:


CI: 
https://app.circleci.com/pipelines/github/frankgh/cassandra?branch=CASSANDRA-17065

> Introduce separate rate limiting settings for entire SSTable streaming
> --
>
> Key: CASSANDRA-17065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17065
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode, Tool/nodetool
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the introduction of entire SSTable streaming, it is desirable to 
> introduce new settings for the rate limit for entire SSTable streaming 
> operations.
> Currently, regular streaming and SSTable streaming are rate limited by the 
> same setting. However, zero-copy streaming reduces load in the JVM and we can 
> have a setting specifically for this use case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-16456) Add Plugin Support for CQLSH

2021-10-25 Thread Brian Houser (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Houser reassigned CASSANDRA-16456:


Assignee: Brian Houser

Beginnning to implement

> 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
>
> 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.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-17066) Blog post: "Harry: A Fuzz Testing Tool for Apache Cassandra"

2021-10-25 Thread Alex Petrov (Jira)
Alex Petrov created CASSANDRA-17066:
---

 Summary: Blog post: "Harry: A Fuzz Testing Tool for Apache 
Cassandra"
 Key: CASSANDRA-17066
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17066
 Project: Cassandra
  Issue Type: Bug
Reporter: Alex Petrov
Assignee: Alex Petrov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Berenguer Blasi (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Berenguer Blasi updated CASSANDRA-16996:

Status: Ready to Commit  (was: Review In Progress)

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0, 4.x
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Berenguer Blasi (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434118#comment-17434118
 ] 

Berenguer Blasi commented on CASSANDRA-16996:
-

As agreed on Slack CI seems good so we're good to merge.

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0, 4.x
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch cassandra-3.11 updated: Prevent broken concurrent schema read/writes

2021-10-25 Thread bereng
This is an automated email from the ASF dual-hosted git repository.

bereng pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
 new fa532a6  Prevent broken concurrent schema read/writes
fa532a6 is described below

commit fa532a61f810b428ccfdf4964684794a7fc0e885
Author: Bereng 
AuthorDate: Wed Oct 20 10:44:50 2021 +0200

Prevent broken concurrent schema read/writes

patch by Berenguer Blasi; reviewed by Caleb Rackliffe for CASSANDRA-16996

Co-authored-by: Berenguer Blasi 
Co-authored-by: Caleb Rackliffe 
---
 src/java/org/apache/cassandra/db/Keyspace.java |   2 +-
 .../apache/cassandra/schema/SchemaKeyspace.java| 175 +++--
 .../cassandra/schema/SchemaKeyspaceTables.java |  77 +
 .../org/apache/cassandra/service/ClientState.java  |  16 +-
 .../cassandra/utils/NativeSSTableLoaderClient.java |  41 +++--
 .../apache/cassandra/config/CFMetaDataTest.java|   8 +-
 .../cassandra/cql3/PstmtPersistenceTest.java   |   8 +-
 test/unit/org/apache/cassandra/cql3/ViewTest.java  |   3 +-
 .../cql3/validation/operations/AlterTest.java  |  14 +-
 .../cql3/validation/operations/CreateTest.java |  20 +--
 .../operations/InsertUpdateIfConditionTest.java|  11 +-
 .../cassandra/schema/SchemaKeyspaceTest.java   |  91 ++-
 .../service/StorageServiceServerTest.java  |  17 +-
 13 files changed, 340 insertions(+), 143 deletions(-)

diff --git a/src/java/org/apache/cassandra/db/Keyspace.java 
b/src/java/org/apache/cassandra/db/Keyspace.java
index 5e39823..eb3de5a 100644
--- a/src/java/org/apache/cassandra/db/Keyspace.java
+++ b/src/java/org/apache/cassandra/db/Keyspace.java
@@ -452,7 +452,7 @@ public class Keyspace
 
 /**
  * If apply is blocking, apply must not be deferred
- * Otherwise there is a race condition where ALL mutation workers are 
beeing blocked ending
+ * Otherwise there is a race condition where ALL mutation workers are 
being blocked ending
  * in a complete deadlock of the mutation stage. See CASSANDRA-12689.
  *
  * @param mutation   the row to write.  Must not be modified after 
calling apply, since commitlog append
diff --git a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java 
b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index 7dc6b23..6b0089f 100644
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@ -21,40 +21,82 @@ import java.nio.ByteBuffer;
 import java.nio.charset.CharacterCodingException;
 import java.security.MessageDigest;
 import java.security.NoSuchAlgorithmException;
-import java.util.*;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Date;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.UUID;
 import java.util.concurrent.TimeUnit;
 import java.util.stream.Collectors;
 
 import com.google.common.annotations.VisibleForTesting;
-import com.google.common.collect.*;
+import com.google.common.collect.ImmutableList;
+import com.google.common.collect.ImmutableSet;
+import com.google.common.collect.MapDifference;
 import com.google.common.collect.Maps;
+
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
-import org.apache.cassandra.config.*;
+import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.CFMetaData.DroppedColumn;
+import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.config.ColumnDefinition.ClusteringOrder;
-import org.apache.cassandra.cql3.*;
-import org.apache.cassandra.cql3.functions.*;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.config.Schema;
+import org.apache.cassandra.config.SchemaConstants;
+import org.apache.cassandra.config.ViewDefinition;
+import org.apache.cassandra.cql3.CQL3Type;
+import org.apache.cassandra.cql3.ColumnIdentifier;
+import org.apache.cassandra.cql3.FieldIdentifier;
+import org.apache.cassandra.cql3.QueryProcessor;
+import org.apache.cassandra.cql3.Terms;
+import org.apache.cassandra.cql3.UntypedResultSet;
+import org.apache.cassandra.cql3.functions.AbstractFunction;
+import org.apache.cassandra.cql3.functions.FunctionName;
+import org.apache.cassandra.cql3.functions.UDAggregate;
+import org.apache.cassandra.cql3.functions.UDFunction;
 import org.apache.cassandra.cql3.statements.SelectStatement;
-import org.apache.cassandra.db.*;
-import org.apache.cassandra.db.marshal.*;
-import org.apache.cassandra.db.partitions.*;
-import org.apache.cassandra.db.rows.*;
+import org.apache.cassandra.db.ColumnFamilyStore;
+import org.apache.cassandra.db.DecoratedKey;
+import org.apache.cassandra.db.Keyspace;
+import org.apache.cassandra.db.Mutation;
+import org.apache.cassandra.db.PartitionRangeRe

[cassandra] branch trunk updated (8e225c5 -> 7d0cb20)

2021-10-25 Thread bereng
This is an automated email from the ASF dual-hosted git repository.

bereng pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 8e225c5  v4+ protocol did not clean up client warnings, which caused 
leaking the state
 new fa532a6  Prevent broken concurrent schema read/writes
 new 5aa2fb8  Merge branch 'cassandra-3.11' into cassandra-4.0
 new 7d0cb20  Merge branch 'cassandra-4.0' into trunk

The 3 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:
 .../org/apache/cassandra/db/SystemKeyspace.java|   2 +-
 .../cassandra/io/sstable/CQLSSTableWriter.java |   2 +-
 .../apache/cassandra/schema/MigrationManager.java  |   2 +-
 src/java/org/apache/cassandra/schema/Schema.java   |  41 -
 .../apache/cassandra/schema/SchemaKeyspace.java|  43 +++--
 .../cassandra/schema/SchemaKeyspaceTables.java |  59 
 .../cassandra/schema/SchemaPullVerbHandler.java|   2 +-
 .../org/apache/cassandra/service/ClientState.java  |   4 +-
 .../cassandra/utils/NativeSSTableLoaderClient.java |  10 +-
 .../distributed/test/metric/TableMetricTest.java   |   2 +-
 .../cassandra/cql3/PstmtPersistenceTest.java   |   4 +-
 test/unit/org/apache/cassandra/cql3/ViewTest.java  |   4 +-
 .../cql3/validation/operations/AlterTest.java  |  16 ++--
 .../cql3/validation/operations/CreateTest.java |  20 ++--
 .../operations/InsertUpdateIfConditionTest.java|  12 +--
 .../org/apache/cassandra/db/DirectoriesTest.java   |   6 +-
 .../apache/cassandra/db/SystemKeyspaceTest.java|   3 +-
 .../cassandra/schema/SchemaKeyspaceTest.java   | 102 +
 .../service/StorageServiceServerTest.java  |   2 +-
 19 files changed, 242 insertions(+), 94 deletions(-)
 create mode 100644 
src/java/org/apache/cassandra/schema/SchemaKeyspaceTables.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0

2021-10-25 Thread bereng
This is an automated email from the ASF dual-hosted git repository.

bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 5aa2fb83e7abff89cf6c59583cdffb5439032c5b
Merge: e8d905e fa532a6
Author: Bereng 
AuthorDate: Tue Oct 26 07:37:33 2021 +0200

Merge branch 'cassandra-3.11' into cassandra-4.0

 .../org/apache/cassandra/db/SystemKeyspace.java|  2 +-
 .../cassandra/io/sstable/CQLSSTableWriter.java |  2 +-
 .../apache/cassandra/schema/MigrationManager.java  |  2 +-
 src/java/org/apache/cassandra/schema/Schema.java   | 42 +-
 .../apache/cassandra/schema/SchemaKeyspace.java| 43 +++---
 .../cassandra/schema/SchemaKeyspaceTables.java | 62 ++
 .../cassandra/schema/SchemaPullVerbHandler.java|  2 +-
 .../org/apache/cassandra/service/ClientState.java  |  4 +-
 .../cassandra/utils/NativeSSTableLoaderClient.java | 14 ++--
 .../distributed/test/metric/TableMetricTest.java   |  3 +-
 .../cassandra/cql3/PstmtPersistenceTest.java   |  4 +-
 test/unit/org/apache/cassandra/cql3/ViewTest.java  |  4 +-
 .../cql3/validation/operations/AlterTest.java  | 16 ++--
 .../cql3/validation/operations/CreateTest.java | 20 ++---
 .../operations/InsertUpdateIfConditionTest.java| 12 +--
 .../org/apache/cassandra/db/DirectoriesTest.java   |  6 +-
 .../apache/cassandra/db/SystemKeyspaceTest.java|  4 +-
 .../cassandra/schema/SchemaKeyspaceTest.java   | 94 +++---
 .../service/StorageServiceServerTest.java  |  2 +-
 19 files changed, 241 insertions(+), 97 deletions(-)

diff --cc src/java/org/apache/cassandra/db/SystemKeyspace.java
index 34973cb,ec26a69..930d09b
--- a/src/java/org/apache/cassandra/db/SystemKeyspace.java
+++ b/src/java/org/apache/cassandra/db/SystemKeyspace.java
@@@ -462,7 -497,7 +462,7 @@@ public final class SystemKeyspac
  
  public static void finishStartup()
  {
--SchemaKeyspace.saveSystemKeyspacesSchema();
++Schema.instance.saveSystemKeyspace();
  }
  
  public static void persistLocalMetadata()
diff --cc src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index 0ac189c,694fe37..8ac0fdf
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@@ -502,16 -513,16 +502,16 @@@ public class CQLSSTableWriter implement
  
  synchronized (CQLSSTableWriter.class)
  {
 -if 
(Schema.instance.getKSMetaData(SchemaConstants.SCHEMA_KEYSPACE_NAME) == null)
 -Schema.instance.load(SchemaKeyspace.metadata());
 -if 
(Schema.instance.getKSMetaData(SchemaConstants.SYSTEM_KEYSPACE_NAME) == null)
 +if 
(Schema.instance.getKeyspaceMetadata(SchemaConstants.SCHEMA_KEYSPACE_NAME) == 
null)
- Schema.instance.load(SchemaKeyspace.metadata());
++Schema.instance.load(Schema.getSystemKeyspaceMetadata());
 +if 
(Schema.instance.getKeyspaceMetadata(SchemaConstants.SYSTEM_KEYSPACE_NAME) == 
null)
  Schema.instance.load(SystemKeyspace.metadata());
  
 -String keyspace = schemaStatement.keyspace();
 +String keyspaceName = schemaStatement.keyspace();
  
 -if (Schema.instance.getKSMetaData(keyspace) == null)
 +if (Schema.instance.getKeyspaceMetadata(keyspaceName) == null)
  {
 -Schema.instance.load(KeyspaceMetadata.create(keyspace,
 +Schema.instance.load(KeyspaceMetadata.create(keyspaceName,
   
KeyspaceParams.simple(1),
   
Tables.none(),
   Views.none(),
diff --cc src/java/org/apache/cassandra/schema/MigrationManager.java
index 87fb603,000..9ebd33d
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/schema/MigrationManager.java
+++ b/src/java/org/apache/cassandra/schema/MigrationManager.java
@@@ -1,365 -1,0 +1,365 @@@
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one
 + * or more contributor license agreements.  See the NOTICE file
 + * distributed with this work for additional information
 + * regarding copyright ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an "AS IS" BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions

[cassandra] branch cassandra-4.0 updated (e8d905e -> 5aa2fb8)

2021-10-25 Thread bereng
This is an automated email from the ASF dual-hosted git repository.

bereng pushed a change to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from e8d905e  Merge branch 'cassandra-3.11' into cassandra-4.0
 new fa532a6  Prevent broken concurrent schema read/writes
 new 5aa2fb8  Merge branch 'cassandra-3.11' into cassandra-4.0

The 2 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:
 .../org/apache/cassandra/db/SystemKeyspace.java|  2 +-
 .../cassandra/io/sstable/CQLSSTableWriter.java |  2 +-
 .../apache/cassandra/schema/MigrationManager.java  |  2 +-
 src/java/org/apache/cassandra/schema/Schema.java   | 42 +-
 .../apache/cassandra/schema/SchemaKeyspace.java| 43 +++---
 .../cassandra/schema/SchemaKeyspaceTables.java | 62 ++
 .../cassandra/schema/SchemaPullVerbHandler.java|  2 +-
 .../org/apache/cassandra/service/ClientState.java  |  4 +-
 .../cassandra/utils/NativeSSTableLoaderClient.java | 14 ++--
 .../distributed/test/metric/TableMetricTest.java   |  3 +-
 .../cassandra/cql3/PstmtPersistenceTest.java   |  4 +-
 test/unit/org/apache/cassandra/cql3/ViewTest.java  |  4 +-
 .../cql3/validation/operations/AlterTest.java  | 16 ++--
 .../cql3/validation/operations/CreateTest.java | 20 ++---
 .../operations/InsertUpdateIfConditionTest.java| 12 +--
 .../org/apache/cassandra/db/DirectoriesTest.java   |  6 +-
 .../apache/cassandra/db/SystemKeyspaceTest.java|  4 +-
 .../cassandra/schema/SchemaKeyspaceTest.java   | 94 +++---
 .../service/StorageServiceServerTest.java  |  2 +-
 19 files changed, 241 insertions(+), 97 deletions(-)
 create mode 100644 
src/java/org/apache/cassandra/schema/SchemaKeyspaceTables.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk

2021-10-25 Thread bereng
This is an automated email from the ASF dual-hosted git repository.

bereng pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 7d0cb2015d76a82a9baf1c4769345ebb5194f212
Merge: 8e225c5 5aa2fb8
Author: Bereng 
AuthorDate: Tue Oct 26 07:44:20 2021 +0200

Merge branch 'cassandra-4.0' into trunk

 .../org/apache/cassandra/db/SystemKeyspace.java|   2 +-
 .../cassandra/io/sstable/CQLSSTableWriter.java |   2 +-
 .../apache/cassandra/schema/MigrationManager.java  |   2 +-
 src/java/org/apache/cassandra/schema/Schema.java   |  41 -
 .../apache/cassandra/schema/SchemaKeyspace.java|  43 +++--
 .../cassandra/schema/SchemaKeyspaceTables.java |  59 
 .../cassandra/schema/SchemaPullVerbHandler.java|   2 +-
 .../org/apache/cassandra/service/ClientState.java  |   4 +-
 .../cassandra/utils/NativeSSTableLoaderClient.java |  10 +-
 .../distributed/test/metric/TableMetricTest.java   |   2 +-
 .../cassandra/cql3/PstmtPersistenceTest.java   |   4 +-
 test/unit/org/apache/cassandra/cql3/ViewTest.java  |   4 +-
 .../cql3/validation/operations/AlterTest.java  |  16 ++--
 .../cql3/validation/operations/CreateTest.java |  20 ++--
 .../operations/InsertUpdateIfConditionTest.java|  12 +--
 .../org/apache/cassandra/db/DirectoriesTest.java   |   6 +-
 .../apache/cassandra/db/SystemKeyspaceTest.java|   3 +-
 .../cassandra/schema/SchemaKeyspaceTest.java   | 102 +
 .../service/StorageServiceServerTest.java  |   2 +-
 19 files changed, 242 insertions(+), 94 deletions(-)

diff --cc src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index e8c22b1,b4a322f..6d5e331
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@@ -58,8 -61,11 +61,11 @@@ import static org.apache.cassandra.sche
  
  /**
   * system_schema.* tables and methods for manipulating them.
+  * 
+  * Please notice this class is _not_ thread safe. It should be accessed 
through {@link org.apache.cassandra.schema.Schema}. See CASSANDRA-16856/16996
   */
+ @NotThreadSafe
 -final class SchemaKeyspace
 +public final class SchemaKeyspace
  {
  private SchemaKeyspace()
  {
@@@ -101,7 -80,7 +80,7 @@@
   * The tables to which we added the cdc column. This is used in {@link 
#makeUpdateForSchema} below to make sure we skip that
   * column is cdc is disabled as the columns breaks pre-cdc to post-cdc 
upgrades (typically, 3.0 -> 3.X).
   */
--private static final Set TABLES_WITH_CDC_ADDED = 
ImmutableSet.of(TABLES, VIEWS);
++private static final Set TABLES_WITH_CDC_ADDED = 
ImmutableSet.of(SchemaKeyspaceTables.TABLES, SchemaKeyspaceTables.VIEWS);
  
  private static final TableMetadata Keyspaces =
  parse(KEYSPACES,
diff --cc src/java/org/apache/cassandra/schema/SchemaKeyspaceTables.java
index 000,b6e825d..c00a4f7
mode 00,100644..100644
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspaceTables.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspaceTables.java
@@@ -1,0 -1,62 +1,59 @@@
+ /*
+  * Licensed to the Apache Software Foundation (ASF) under one
+  * or more contributor license agreements.  See the NOTICE file
+  * distributed with this work for additional information
+  * regarding copyright ownership.  The ASF licenses this file
+  * to you under the Apache License, Version 2.0 (the
+  * "License"); you may not use this file except in compliance
+  * with the License.  You may obtain a copy of the License at
+  *
+  * http://www.apache.org/licenses/LICENSE-2.0
+  *
+  * Unless required by applicable law or agreed to in writing, software
+  * distributed under the License is distributed on an "AS IS" BASIS,
+  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  * See the License for the specific language governing permissions and
+  * limitations under the License.
+  */
+ package org.apache.cassandra.schema;
+ 
+ import com.google.common.collect.ImmutableList;
+ 
 -public final class SchemaKeyspaceTables
++public class SchemaKeyspaceTables
+ {
 -public static final String INDEXES = "indexes";
 -public static final String AGGREGATES = "aggregates";
 -public static final String FUNCTIONS = "functions";
 -public static final String TYPES = "types";
 -public static final String VIEWS = "views";
 -public static final String TRIGGERS = "triggers";
 -public static final String DROPPED_COLUMNS = "dropped_columns";
 -public static final String COLUMNS = "columns";
 -public static final String TABLES = "tables";
+ public static final String KEYSPACES = "keyspaces";
 -
++public static final String TABLES = "tables";
++public static final String COLUMNS = "columns";
++public static final String DROPPED_COLUMNS = "dropped_columns";
++public static final String TRIGGERS = "triggers";
++public static final String VIEWS = "vi

[jira] [Updated] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Berenguer Blasi (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Berenguer Blasi updated CASSANDRA-16996:

  Fix Version/s: (was: 3.11.x)
 (was: 4.x)
 4.1
 3.11.12
  Since Version: 3.11.0
Source Control Link: 
https://github.com/apache/cassandra/commit/fa532a61f810b428ccfdf4964684794a7fc0e885
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.12, 4.1, 4.0
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16996) Prevent broken concurrent schema read/writes

2021-10-25 Thread Berenguer Blasi (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434123#comment-17434123
 ] 

Berenguer Blasi commented on CASSANDRA-16996:
-

Committed thx for the patience where we talking past each other :-)

> Prevent broken concurrent schema read/writes
> 
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.12, 4.1, 4.0
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org