[jira] [Commented] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690417#comment-16690417 ] Vinay Chella commented on CASSANDRA-14498: -- [~krummas] Updated the patch to fix the tests (attached patch worked on trunk without CASSANDRA-13668 changes). Below is the branch and CircleCI unit tests, there is one unit test failing which is being addressed in CASSANDRA-14889 ||trunk||Circle CI|| |[trunk_CASS-14498|https://github.com/vinaykumarchella/cassandra/tree/trunk_CASS-14498]|[utests|https://circleci.com/gh/vinaykumarchella/cassandra/321#tests/containers/68]| > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14829) Make stop-server.bat wait for Cassandra to terminate
[ https://issues.apache.org/jira/browse/CASSANDRA-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690054#comment-16690054 ] Dinesh Joshi commented on CASSANDRA-14829: -- Hi Georg, Thanks for reporting this. The change looks reasonable. Would you be able to write a dtest for this? [https://github.com/apache/cassandra-dtest] > Make stop-server.bat wait for Cassandra to terminate > > > Key: CASSANDRA-14829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14829 > Project: Cassandra > Issue Type: Improvement > Components: Packaging > Environment: Windows 10 >Reporter: Georg Dietrich >Assignee: Georg Dietrich >Priority: Minor > Labels: easyfix, windows > Fix For: 3.11.x, 4.x, 4.0.x > > > While administering a single node Cassandra on Windows, I noticed that the > stop-server.bat script returns before the cassandra process has actually > terminated. For use cases like creating a script "shut down & create backup > of data directory without having to worry about open files, then restart", it > would be good to make stop-server.bat wait for Cassandra to terminate. > All that is needed for that is to change in > apache-cassandra-3.11.3\bin\stop-server.bat "start /B powershell /file ..." > to "start /WAIT /B powershell /file ..." (additional /WAIT parameter). > Does this sound reasonable? > Here is the pull request: https://github.com/apache/cassandra/pull/287 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690082#comment-16690082 ] Vinay Chella commented on CASSANDRA-14498: -- Thanks for reviewing, I am looking into those failed tests. > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690081#comment-16690081 ] Vinay Chella commented on CASSANDRA-14821: -- This is great. Sure [~ifesdjeen], that works. you can reach out to us on dev-irc. > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14829) Make stop-server.bat wait for Cassandra to terminate
[ https://issues.apache.org/jira/browse/CASSANDRA-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-14829: - Reviewers: Dinesh Joshi > Make stop-server.bat wait for Cassandra to terminate > > > Key: CASSANDRA-14829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14829 > Project: Cassandra > Issue Type: Improvement > Components: Packaging > Environment: Windows 10 >Reporter: Georg Dietrich >Assignee: Georg Dietrich >Priority: Minor > Labels: easyfix, windows > Fix For: 3.11.x, 4.x, 4.0.x > > > While administering a single node Cassandra on Windows, I noticed that the > stop-server.bat script returns before the cassandra process has actually > terminated. For use cases like creating a script "shut down & create backup > of data directory without having to worry about open files, then restart", it > would be good to make stop-server.bat wait for Cassandra to terminate. > All that is needed for that is to change in > apache-cassandra-3.11.3\bin\stop-server.bat "start /B powershell /file ..." > to "start /WAIT /B powershell /file ..." (additional /WAIT parameter). > Does this sound reasonable? > Here is the pull request: https://github.com/apache/cassandra/pull/287 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690003#comment-16690003
]
Boris Onufriyev commented on CASSANDRA-11323:
-
Thanks for the feedback [~aweisberg].
I added the better log message as well as NoSpamLogger for the ignore policy.
Here are the new patches for those 3 branches:
||3.0||3.11||trunk||
|[^11323-3.0.txt]|[^11323-3.11.txt]|[^11323-trunk.txt]|
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.11.txt,
> 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Onufriyev updated CASSANDRA-11323:
Attachment: 11323-trunk.txt
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.11.txt,
> 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Onufriyev updated CASSANDRA-11323:
Attachment: 11323-3.0.txt
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.11.txt,
> 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Onufriyev updated CASSANDRA-11323:
Attachment: 11323-3.11.txt
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.11.txt,
> 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14869) Range.subtractContained produces incorrect results when used on full ring
[
https://issues.apache.org/jira/browse/CASSANDRA-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689954#comment-16689954
]
Alex Petrov commented on CASSANDRA-14869:
-
Builds:
|[3.0|https://circleci.com/workflow-run/dec6ad52-121f-4bd6-92f9-95d52b041ec9]|[3.11|https://circleci.com/workflow-run/02340ed3-5b7f-4e8e-a51f-2192cdd93612]|[trunk|https://circleci.com/workflow-run/7de63da3-3977-4ace-aeef-be5430b9bc37]|
> Range.subtractContained produces incorrect results when used on full ring
> -
>
> Key: CASSANDRA-14869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14869
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: range bug.jpg
>
>
> Currently {{Range.subtractContained}} returns incorrect results if minuend
> range covers full ring and:
> * subtrahend range wraps around. For example, {{(50, 50] - (10, 100]}}
> returns {{\{(50,10], (100,50]\}}} instead of {{(100,10]}}
> * subtrahend range covers the full ring as well. For example {{(50, 50] - (0,
> 0]}} returns {{\{(0,50], (50,0]\}}} instead of {{\{\}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14560) rebuild_test.py: Fix broken pytest.raises using incorrect kwarg
[ https://issues.apache.org/jira/browse/CASSANDRA-14560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg resolved CASSANDRA-14560. Resolution: Duplicate > rebuild_test.py: Fix broken pytest.raises using incorrect kwarg > --- > > Key: CASSANDRA-14560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14560 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > This was missed in the Python 2/3 conversion I guess. It uses the wrong > signature for the keyword argument and for some reason it has started showing > up as an error now. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14560) rebuild_test.py: Fix broken pytest.raises using incorrect kwarg
[ https://issues.apache.org/jira/browse/CASSANDRA-14560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14560: --- Status: Open (was: Ready to Commit) > rebuild_test.py: Fix broken pytest.raises using incorrect kwarg > --- > > Key: CASSANDRA-14560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14560 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > This was missed in the Python 2/3 conversion I guess. It uses the wrong > signature for the keyword argument and for some reason it has started showing > up as an error now. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella reassigned CASSANDRA-14898:
Assignee: Joseph Lynch
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689842#comment-16689842 ] Alex Petrov commented on CASSANDRA-14821: - [~jolynch] I will, thank you for interest! I'll reach out next week if that's ok. [~benedict] [~djoshi3] thank you very much for review & feedback! Committed to trunk with [f22fec927de7ac29120c2f34de5b8cc1c695|https://github.com/apache/cassandra/commit/f22fec927de7ac29120c2f34de5b8cc1c695]. > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14821: Status: Ready to Commit (was: Patch Available) > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14821: Resolution: Fixed Status: Resolved (was: Ready to Commit) > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[2/3] cassandra git commit: Introduce in-jvm distributed tests
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f22fec92/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 630dc5d..439d8cf 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -18,7 +18,6 @@
package org.apache.cassandra.service;
import java.io.File;
-import java.lang.management.ManagementFactory;
import java.nio.ByteBuffer;
import java.nio.file.Paths;
import java.util.*;
@@ -26,9 +25,6 @@ import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;
-import javax.management.MBeanServer;
-import javax.management.ObjectName;
-
import com.google.common.base.Preconditions;
import com.google.common.base.Strings;
import com.google.common.cache.CacheLoader;
@@ -123,16 +119,7 @@ public class StorageProxy implements StorageProxyMBean
static
{
-MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
-try
-{
-mbs.registerMBean(instance, new ObjectName(MBEAN_NAME));
-}
-catch (Exception e)
-{
-throw new RuntimeException(e);
-}
-
+MBeanWrapper.instance.registerMBean(instance, MBEAN_NAME);
HintsService.instance.registerMBean();
HintedHandOffManager.instance.registerMBean();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f22fec92/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index e7ca4be..68dba93 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -231,7 +231,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
private final List lifecycleSubscribers =
new CopyOnWriteArrayList<>();
-private final ObjectName jmxObjectName;
+private final String jmxObjectName;
private Collection bootstrapTokens = null;
@@ -270,17 +270,9 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
// use dedicated executor for handling JMX notifications
super(JMXBroadcastExecutor.executor);
-MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
-try
-{
-jmxObjectName = new
ObjectName("org.apache.cassandra.db:type=StorageService");
-mbs.registerMBean(this, jmxObjectName);
-mbs.registerMBean(StreamManager.instance, new
ObjectName(StreamManager.OBJECT_NAME));
-}
-catch (Exception e)
-{
-throw new RuntimeException(e);
-}
+jmxObjectName = "org.apache.cassandra.db:type=StorageService";
+MBeanWrapper.instance.registerMBean(this, jmxObjectName);
+MBeanWrapper.instance.registerMBean(StreamManager.instance,
StreamManager.OBJECT_NAME);
ReadCommandVerbHandler readHandler = new ReadCommandVerbHandler();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f22fec92/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
b/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
index 151eb18..50d35bc 100644
--- a/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
+++ b/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
@@ -471,6 +471,32 @@ public class ByteBufferUtil
return bytes.getDouble(bytes.position());
}
+public static ByteBuffer objectToBytes(Object obj)
+{
+if (obj instanceof Integer)
+return ByteBufferUtil.bytes((int) obj);
+else if (obj instanceof Byte)
+return ByteBufferUtil.bytes((byte) obj);
+else if (obj instanceof Short)
+return ByteBufferUtil.bytes((short) obj);
+else if (obj instanceof Long)
+return ByteBufferUtil.bytes((long) obj);
+else if (obj instanceof Float)
+return ByteBufferUtil.bytes((float) obj);
+else if (obj instanceof Double)
+return ByteBufferUtil.bytes((double) obj);
+else if (obj instanceof UUID)
+return ByteBufferUtil.bytes((UUID) obj);
+else if (obj instanceof InetAddress)
+return ByteBufferUtil.bytes((InetAddress) obj);
+else if (obj instanceof String)
+return ByteBufferUtil.bytes((String) obj);
+else
+throw new IllegalArgumentException(String.format("Cannot convert
value %s of type %s",
+
[1/3] cassandra git commit: Introduce in-jvm distributed tests
Repository: cassandra
Updated Branches:
refs/heads/trunk 787703508 -> f22fec927
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f22fec92/test/distributed/org/apache/cassandra/distributed/MessageFilters.java
--
diff --git
a/test/distributed/org/apache/cassandra/distributed/MessageFilters.java
b/test/distributed/org/apache/cassandra/distributed/MessageFilters.java
new file mode 100644
index 000..f488e08
--- /dev/null
+++ b/test/distributed/org/apache/cassandra/distributed/MessageFilters.java
@@ -0,0 +1,175 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.concurrent.CopyOnWriteArraySet;
+import java.util.function.BiConsumer;
+
+import org.apache.cassandra.locator.InetAddressAndPort;
+import org.apache.cassandra.net.MessagingService;
+
+public class MessageFilters
+{
+private final TestCluster cluster;
+private final Set filters = new CopyOnWriteArraySet<>();
+
+public MessageFilters(TestCluster cluster)
+{
+this.cluster = cluster;
+}
+
+BiConsumer
filter(BiConsumer applyIfNotFiltered)
+{
+return (toAddress, message) ->
+{
+int from = cluster.get(message.from).config.num;
+int to = cluster.get(toAddress).config.num;
+int verb = message.verb;
+for (Filter filter : filters)
+{
+if (filter.matches(from, to, verb))
+return;
+}
+
+applyIfNotFiltered.accept(toAddress, message);
+};
+}
+
+public class Filter
+{
+final int[] from;
+final int[] to;
+final int[] verbs;
+
+Filter(int[] from, int[] to, int[] verbs)
+{
+if (from != null)
+{
+from = from.clone();
+Arrays.sort(from);
+}
+if (to != null)
+{
+to = to.clone();
+Arrays.sort(to);
+}
+if (verbs != null)
+{
+verbs = verbs.clone();
+Arrays.sort(verbs);
+}
+this.from = from;
+this.to = to;
+this.verbs = verbs;
+}
+
+public int hashCode()
+{
+return (from == null ? 0 : Arrays.hashCode(from))
++ (to == null ? 0 : Arrays.hashCode(to))
++ (verbs == null ? 0 : Arrays.hashCode(verbs));
+}
+
+public boolean equals(Object that)
+{
+return that instanceof Filter && equals((Filter) that);
+}
+
+public boolean equals(Filter that)
+{
+return Arrays.equals(from, that.from)
+&& Arrays.equals(to, that.to)
+&& Arrays.equals(verbs, that.verbs);
+}
+
+public boolean matches(int from, int to, int verb)
+{
+return (this.from == null || Arrays.binarySearch(this.from, from)
>= 0)
+&& (this.to == null || Arrays.binarySearch(this.to, to) >=
0)
+&& (this.verbs == null || Arrays.binarySearch(this.verbs,
verb) >= 0);
+}
+
+public Filter restore()
+{
+filters.remove(this);
+return this;
+}
+
+public Filter drop()
+{
+filters.add(this);
+return this;
+}
+}
+
+public class Builder
+{
+int[] from;
+int[] to;
+int[] verbs;
+
+private Builder(int[] verbs)
+{
+this.verbs = verbs;
+}
+
+public Builder from(int ... nums)
+{
+from = nums;
+return this;
+}
+
+public Builder to(int ... nums)
+{
+to = nums;
+return this;
+}
+
+public Filter ready()
+{
+return new Filter(from, to, verbs);
+}
+
+public Filter drop()
+{
+return ready().drop();
+}
+}
+
+public Builder verbs(Messaging
[3/3] cassandra git commit: Introduce in-jvm distributed tests
Introduce in-jvm distributed tests Patch by Alex Petrov and Benedict Elliott Smith; reviewed by Benedict Elliott Smith and Dinesh Joshi for CASSANDRA-14821. Co-authored-by: Benedict Elliott Smith Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f22fec92 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f22fec92 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f22fec92 Branch: refs/heads/trunk Commit: f22fec927de7ac29120c2f34de5b8cc1c695 Parents: 7877035 Author: Alex Petrov Authored: Fri Nov 16 19:41:58 2018 +0100 Committer: Alex Petrov Committed: Fri Nov 16 19:41:58 2018 +0100 -- .circleci/config.yml| 14 +- build.xml | 10 +- ide/idea-iml-file.xml | 1 + .../org/apache/cassandra/auth/AuthCache.java| 33 +- .../cassandra/batchlog/BatchlogManager.java | 48 ++- .../concurrent/InfiniteLoopExecutor.java| 83 .../JMXEnabledThreadPoolExecutor.java | 24 +- .../concurrent/ScheduledExecutors.java | 15 + .../concurrent/SharedExecutorPool.java | 15 +- .../cassandra/concurrent/StageManager.java | 10 + .../cassandra/config/DatabaseDescriptor.java| 8 +- .../apache/cassandra/cql3/QueryProcessor.java | 6 +- .../cassandra/db/BlacklistedDirectories.java| 17 +- .../apache/cassandra/db/ColumnFamilyStore.java | 48 ++- .../cassandra/db/HintedHandOffManager.java | 15 +- .../cassandra/db/commitlog/CommitLog.java | 15 +- .../db/compaction/CompactionManager.java| 18 +- .../cassandra/diag/DiagnosticEventService.java | 13 +- .../cassandra/diag/LastEventIdBroadcaster.java | 16 +- .../apache/cassandra/gms/FailureDetector.java | 14 +- src/java/org/apache/cassandra/gms/Gossiper.java | 14 +- .../apache/cassandra/hints/HintsService.java| 15 +- .../cassandra/index/SecondaryIndexManager.java | 10 + .../io/sstable/IndexSummaryManager.java | 30 +- .../cassandra/io/util/DataInputBuffer.java | 8 +- .../locator/DynamicEndpointSnitch.java | 24 +- .../cassandra/locator/EndpointSnitchInfo.java | 16 +- .../metrics/CassandraMetricsRegistry.java | 30 +- .../cassandra/net/ForwardToContainer.java | 3 +- .../org/apache/cassandra/net/MessageIn.java | 12 +- .../apache/cassandra/net/MessagingService.java | 28 +- .../net/async/ByteBufDataInputPlus.java | 8 + .../cassandra/net/async/MessageInHandler.java | 67 +++- .../net/async/MessageInHandlerPre40.java| 50 ++- .../cassandra/net/async/NettyFactory.java | 12 +- .../apache/cassandra/schema/SchemaEvent.java| 5 +- .../cassandra/service/ActiveRepairService.java | 15 +- .../apache/cassandra/service/CacheService.java | 16 +- .../cassandra/service/CassandraDaemon.java | 11 +- .../service/PendingRangeCalculatorService.java | 9 + .../apache/cassandra/service/StorageProxy.java | 15 +- .../cassandra/service/StorageService.java | 16 +- .../apache/cassandra/utils/ByteBufferUtil.java | 26 ++ .../apache/cassandra/utils/MBeanWrapper.java| 179 + .../org/apache/cassandra/utils/Mx4jTool.java| 4 +- .../apache/cassandra/utils/concurrent/Ref.java | 35 +- .../cassandra/utils/memory/BufferPool.java | 43 +- .../utils/memory/MemtableCleanerThread.java | 77 ++-- .../cassandra/utils/memory/MemtablePool.java| 9 + test/conf/logback-dtest.xml | 79 .../cassandra/distributed/Coordinator.java | 80 .../DistributedReadWritePathTest.java | 348 .../distributed/DistributedTestBase.java| 86 .../apache/cassandra/distributed/Instance.java | 399 +++ .../distributed/InstanceClassLoader.java| 101 + .../cassandra/distributed/InstanceConfig.java | 87 .../distributed/InstanceIDDefiner.java | 38 ++ .../distributed/InvokableInstance.java | 133 +++ .../apache/cassandra/distributed/Message.java | 41 ++ .../cassandra/distributed/MessageFilters.java | 175 .../apache/cassandra/distributed/RowUtil.java | 47 +++ .../cassandra/distributed/TestCluster.java | 308 ++ .../cassandra/net/async/NettyFactoryTest.java | 2 +- .../async/StreamCompressionSerializerTest.java | 4 - 64 files changed, 2661 insertions(+), 477 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f22fec92/.circleci/config.yml -- diff --git a/.circleci/config.yml b/.circleci/config.yml index 430354a..3b2b978 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -164,12 +164,20 @
[jira] [Assigned] (CASSANDRA-13196) test failure in snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address
[
https://issues.apache.org/jira/browse/CASSANDRA-13196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov reassigned CASSANDRA-13196:
Assignee: (was: Aleksandr Sorokoumov)
> test failure in
> snitch_test.TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address
> -
>
> Key: CASSANDRA-13196
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13196
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Priority: Major
> Labels: dtest, test-failure
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1487/testReport/snitch_test/TestGossipingPropertyFileSnitch/test_prefer_local_reconnect_on_listen_address
> {code}
> {novnode}
> Error Message
> Error from server: code=2200 [Invalid query] message="keyspace keyspace1 does
> not exist"
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-k6b0iF
> dtest: DEBUG: Done setting configuration options:
> { 'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> cassandra.policies: INFO: Using datacenter 'dc1' for DCAwareRoundRobinPolicy
> (via host '127.0.0.1'); if incorrect, please specify a local_dc to the
> constructor, or limit contact points to local cluster nodes
> cassandra.cluster: INFO: New Cassandra host discovered
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/snitch_test.py", line 87, in
> test_prefer_local_reconnect_on_listen_address
> new_rows = list(session.execute("SELECT * FROM {}".format(stress_table)))
> File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line
> 1998, in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state).result()
> File "/home/automaton/src/cassandra-driver/cassandra/cluster.py", line
> 3784, in result
> raise self._final_exception
> 'Error from server: code=2200 [Invalid query] message="keyspace keyspace1
> does not exist"\n >> begin captured logging <<
> \ndtest: DEBUG: cluster ccm directory:
> /tmp/dtest-k6b0iF\ndtest: DEBUG: Done setting configuration options:\n{
> \'initial_token\': None,\n\'num_tokens\': \'32\',\n
> \'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n
> \'read_request_timeout_in_ms\': 1,\n\'request_timeout_in_ms\':
> 1,\n\'truncate_request_timeout_in_ms\': 1,\n
> \'write_request_timeout_in_ms\': 1}\ncassandra.policies: INFO: Using
> datacenter \'dc1\' for DCAwareRoundRobinPolicy (via host \'127.0.0.1\'); if
> incorrect, please specify a local_dc to the constructor, or limit contact
> points to local cluster nodes\ncassandra.cluster: INFO: New Cassandra host
> discovered\n- >> end captured
> logging << -'
> {novnode}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14900) DigestMismatchException log messages should be at TRACE
[
https://issues.apache.org/jira/browse/CASSANDRA-14900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14900:
-
Component/s: Observability
Configuration
> DigestMismatchException log messages should be at TRACE
> ---
>
> Key: CASSANDRA-14900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration, Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> DigestMismatchException log messages should probably be at TRACE. These log
> messages about normal digest mismatches that include scary stacktraces:
> {noformat}
> DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-786225366477494582,
> 31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
> (943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
> at
> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-14498: Status: Open (was: Ready to Commit) seems a bunch of unit tests fail: https://circleci.com/gh/krummas/cassandra/1031#tests/containers/13 > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14869) Range.subtractContained produces incorrect results when used on full ring
[
https://issues.apache.org/jira/browse/CASSANDRA-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689510#comment-16689510
]
Aleksandr Sorokoumov commented on CASSANDRA-14869:
--
[~ifesdjeen] Thanks for running the builds! I've tested all failing tests
locally on {{cassandra-3.0}} and {{trunk}} right before my commit and they
still fail in the same way.
> Range.subtractContained produces incorrect results when used on full ring
> -
>
> Key: CASSANDRA-14869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14869
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: range bug.jpg
>
>
> Currently {{Range.subtractContained}} returns incorrect results if minuend
> range covers full ring and:
> * subtrahend range wraps around. For example, {{(50, 50] - (10, 100]}}
> returns {{\{(50,10], (100,50]\}}} instead of {{(100,10]}}
> * subtrahend range covers the full ring as well. For example {{(50, 50] - (0,
> 0]}} returns {{\{(0,50], (50,0]\}}} instead of {{\{\}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14826) cassandra spinning forever on 1 thread while initializing keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-14826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689483#comment-16689483
]
Marcus Eriksson edited comment on CASSANDRA-14826 at 11/16/18 2:36 PM:
---
patches to bulk-add the sstables instead of one-by-one
3.0: https://github.com/krummas/cassandra/commits/marcuse/14826-3.0
3.11: https://github.com/krummas/cassandra/commits/marcuse/14826-3.11
trunk: https://github.com/krummas/cassandra/commits/marcuse/14826-trunk
tests:
3.0:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.0
3.11:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.11
trunk:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-trunk
do you have a test system where could you try the patch out [~ingard]?
edit: note that it slightly changes behaviour when mutating the level on an
sstable fails - it used to just add it to L0 which would eventually make
compaction stop for the table (since we wouldn't remove it from L0 when the
compaction finished and we could then pick the same non-existing sstable again
and that would fail). Now that sstable is marked suspect and won't be picked
for any future compactions (until restart)
was (Author: krummas):
patches to bulk-add the sstables instead of one-by-one
3.0: https://github.com/krummas/cassandra/commits/marcuse/14826-3.0
3.11: https://github.com/krummas/cassandra/commits/marcuse/14826-3.11
trunk: https://github.com/krummas/cassandra/commits/marcuse/14826-trunk
tests:
3.0:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.0
3.11:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.11
trunk:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-trunk
do you have a test system where could you try the patch out [~ingard]?
edit: note that it slightly changes behaviour when mutating the level on an
sstable changes - it used to just add it to L0 which would eventually make
compaction stop for the table (since we wouldn't remove it from L0 when the
compaction finished and we could then pick the same non-existing sstable again
and that would fail). Now that sstable is marked suspect and won't be picked
for any future compactions (until restart)
> cassandra spinning forever on 1 thread while initializing keyspace
> --
>
> Key: CASSANDRA-14826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14826
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
>Reporter: ingard mevåg
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2018-10-16 at 14.51.27.png
>
>
> When starting cassandra 3.0.17 it takes a long time to initialize a keyspace.
> top shows 1 thread spinning at 100% cpu. Thread dump shows:
> {code:java}
> "main" - Thread t@1
> java.lang.Thread.State: RUNNABLE
> at java.util.TimSort.mergeHi(TimSort.java:850)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.canAddSSTable(LeveledManifest.java:243)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.add(LeveledManifest.java:146)
> - locked (a
> org.apache.cassandra.db.compaction.LeveledManifest)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:298)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:135)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:187)
> - locked <742bfce7> (a
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.(CompactionStrategyManager.java:75)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:408)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:363)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:579)
> - locked <4e4f20d2> (a java.lang.Class)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:556)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
>
[jira] [Comment Edited] (CASSANDRA-14826) cassandra spinning forever on 1 thread while initializing keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-14826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689483#comment-16689483
]
Marcus Eriksson edited comment on CASSANDRA-14826 at 11/16/18 2:36 PM:
---
patches to bulk-add the sstables instead of one-by-one
3.0: https://github.com/krummas/cassandra/commits/marcuse/14826-3.0
3.11: https://github.com/krummas/cassandra/commits/marcuse/14826-3.11
trunk: https://github.com/krummas/cassandra/commits/marcuse/14826-trunk
tests:
3.0:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.0
3.11:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.11
trunk:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-trunk
do you have a test system where could you try the patch out [~ingard]?
edit: note that it slightly changes behaviour when mutating the level on an
sstable changes - it used to just add it to L0 which would eventually make
compaction stop for the table (since we wouldn't remove it from L0 when the
compaction finished and we could then pick the same non-existing sstable again
and that would fail). Now that sstable is marked suspect and won't be picked
for any future compactions (until restart)
was (Author: krummas):
patches to bulk-add the sstables instead of one-by-one
3.0: https://github.com/krummas/cassandra/commits/marcuse/14826-3.0
3.11: https://github.com/krummas/cassandra/commits/marcuse/14826-3.11
trunk: https://github.com/krummas/cassandra/commits/marcuse/14826-trunk
tests:
3.0:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.0
3.11:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.11
trunk:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-trunk
do you have a test system where could you try the patch out [~ingard]?
> cassandra spinning forever on 1 thread while initializing keyspace
> --
>
> Key: CASSANDRA-14826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14826
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
>Reporter: ingard mevåg
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2018-10-16 at 14.51.27.png
>
>
> When starting cassandra 3.0.17 it takes a long time to initialize a keyspace.
> top shows 1 thread spinning at 100% cpu. Thread dump shows:
> {code:java}
> "main" - Thread t@1
> java.lang.Thread.State: RUNNABLE
> at java.util.TimSort.mergeHi(TimSort.java:850)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.canAddSSTable(LeveledManifest.java:243)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.add(LeveledManifest.java:146)
> - locked (a
> org.apache.cassandra.db.compaction.LeveledManifest)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:298)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:135)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:187)
> - locked <742bfce7> (a
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.(CompactionStrategyManager.java:75)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:408)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:363)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:579)
> - locked <4e4f20d2> (a java.lang.Class)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:556)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> - locked <5318346c> (a java.lang.Class)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:262)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(Cassandra
[jira] [Updated] (CASSANDRA-14826) cassandra spinning forever on 1 thread while initializing keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-14826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14826:
Fix Version/s: 4.x
3.11.x
3.0.x
Status: Patch Available (was: Open)
patches to bulk-add the sstables instead of one-by-one
3.0: https://github.com/krummas/cassandra/commits/marcuse/14826-3.0
3.11: https://github.com/krummas/cassandra/commits/marcuse/14826-3.11
trunk: https://github.com/krummas/cassandra/commits/marcuse/14826-trunk
tests:
3.0:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.0
3.11:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-3.11
trunk:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F14826-trunk
do you have a test system where could you try the patch out [~ingard]?
> cassandra spinning forever on 1 thread while initializing keyspace
> --
>
> Key: CASSANDRA-14826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14826
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
>Reporter: ingard mevåg
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2018-10-16 at 14.51.27.png
>
>
> When starting cassandra 3.0.17 it takes a long time to initialize a keyspace.
> top shows 1 thread spinning at 100% cpu. Thread dump shows:
> {code:java}
> "main" - Thread t@1
> java.lang.Thread.State: RUNNABLE
> at java.util.TimSort.mergeHi(TimSort.java:850)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.canAddSSTable(LeveledManifest.java:243)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.add(LeveledManifest.java:146)
> - locked (a
> org.apache.cassandra.db.compaction.LeveledManifest)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:298)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:135)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:187)
> - locked <742bfce7> (a
> org.apache.cassandra.db.compaction.CompactionStrategyManager)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.(CompactionStrategyManager.java:75)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:408)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:363)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:579)
> - locked <4e4f20d2> (a java.lang.Class)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:556)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> - locked <5318346c> (a java.lang.Class)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:262)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14900) DigestMismatchException log messages should be at TRACE
[
https://issues.apache.org/jira/browse/CASSANDRA-14900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-14900:
-
Status: Patch Available (was: Open)
||3.0 | [patch | https://github.com/Ge/cassandra/tree/14900-3.0] | [test |
https://gist.github.com/Ge/484e2dd1081aa78504f7cbbf5774530b]|
||3.11| [patch | https://github.com/Ge/cassandra/tree/14900-3.11] | [test |
https://gist.github.com/Ge/0bccf5ccd9fc66b62fde8174360e4635]|
> DigestMismatchException log messages should be at TRACE
> ---
>
> Key: CASSANDRA-14900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
> Project: Cassandra
> Issue Type: Bug
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> DigestMismatchException log messages should probably be at TRACE. These log
> messages about normal digest mismatches that include scary stacktraces:
> {noformat}
> DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-786225366477494582,
> 31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
> (943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
> at
> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
> ~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [cassandra-all-3.11.0.1855.jar:3.11.0.1855]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689469#comment-16689469
]
Amanda R Debrot commented on CASSANDRA-11939:
-
Great! Thanks.
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Assignee: Amanda R Debrot
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-2.2.txt, 11939-3.0.txt,
> 11939-3.0.txt, 11939-3.11.txt, 11939-3.11.txt, 11939-output.txt,
> 11939-trunk.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-14498: Status: Ready to Commit (was: Patch Available) > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-14498: Reviewers: Marcus Eriksson, Per Otterström Reviewer: (was: Marcus Eriksson) > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689456#comment-16689456
]
Tommy Stendahl commented on CASSANDRA-14848:
I have created a patch that allow 4.0 nodes to connect to all 3.x nodes, its
available here:
[cassandra-14848|[https://github.com/tommystendahl/cassandra/tree/cassandra-14848].]
Unfortunately I got another exception in the log of the old nodes:
{noformat}
2018-11-16T13:48:15.165+0100 [MessagingService-Incoming-/10.216.193.242] ERROR
o.a.c.service.CassandraDaemon$2:223 uncaughtException Exception in thread
Thread[MessagingService-Incoming-/10.216.193.242,5,main]
java.lang.RuntimeException: Unknown column additional_write_policy during
deserialization
at org.apache.cassandra.db.Columns$Serializer.deserialize(Columns.java:433)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.SerializationHeader$Serializer.deserializeForMessaging(SerializationHeader.java:440)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.deserializeHeader(UnfilteredRowIteratorSerializer.java:190)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:686)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:674)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:337)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:346)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.service.MigrationManager$MigrationsSerializer.deserialize(MigrationManager.java:641)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.service.MigrationManager$MigrationsSerializer.deserialize(MigrationManager.java:624)
~[apache-cassandra-3.0.17.jar:3.0.17]
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178)
~[apache-cassandra-3.0.17.jar:3.0.17]
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92)
~[apache-cassandra-3.0.17.jar:3.0.17]{noformat}
It appears once or twice about one minute after the old node has detected the
new node as being UP:
{noformat}
2018-11-16T13:47:15.148+0100 [GossipStage:1] INFO
org.apache.cassandra.gms.Gossiper:1040 handleMajorStateChange Node
/10.216.193.242 has restarted, now UP
2018-11-16T13:47:15.149+0100 [GossipStage:1] INFO
o.a.cassandra.service.StorageService:2024 handleStateNormal Node
/10.216.193.242 state jump to NORMAL
2018-11-16T13:48:15.165+0100 [MessagingService-Incoming-/10.216.193.242] ERROR
o.a.c.service.CassandraDaemon$2:223 uncaughtException Exception in thread
Thread[MessagingService-Incoming-/10.216.193.242,5,main]
java.lang.RuntimeException: Unknown column additional_write_policy during
deserialization{noformat}
So far I have not found this to cause any problems besides printing an
unexpected exception in the log. Also I'm not sure if we should consider this a
new issue or if my patch is wrong (or missing something).
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Tommy Stendahl
>Priority: Major
> Labels: security
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.
[jira] [Commented] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689455#comment-16689455 ] Marcus Eriksson commented on CASSANDRA-14498: - this lgtm, with a tiny nit: https://github.com/krummas/cassandra/commit/ae103bfef73abdaa5f91bb7a0be75cbcbcd3ae62 running tests here: https://circleci.com/workflow-run/1d78e8cc-98a2-4acd-af47-505064f94c6f - will commit if they look ok > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14900) DigestMismatchException log messages should be at TRACE
Aleksandr Sorokoumov created CASSANDRA-14900:
Summary: DigestMismatchException log messages should be at TRACE
Key: CASSANDRA-14900
URL: https://issues.apache.org/jira/browse/CASSANDRA-14900
Project: Cassandra
Issue Type: Bug
Reporter: Aleksandr Sorokoumov
Assignee: Aleksandr Sorokoumov
Fix For: 3.0.x, 3.11.x
DigestMismatchException log messages should probably be at TRACE. These log
messages about normal digest mismatches that include scary stacktraces:
{noformat}
DEBUG [ReadRepairStage:40] 2017-10-24 19:45:50,349 ReadCallback.java:242 -
Digest mismatch:
org.apache.cassandra.service.DigestMismatchException: Mismatch for key
DecoratedKey(-786225366477494582,
31302e33322e37382e31332d6765744469736b5574696c50657263656e742d736463)
(943070f62d72259e3c25be0c6f76e489 vs f4c7c7675c803e0028992e11e0bbc5a0)
at
org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
at
org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
~[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_121]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_121]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
[cassandra-all-3.11.0.1855.jar:3.11.0.1855]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14899) Cannot perform slice reads in reverse direction against tables with clustering columns in mixed order
[
https://issues.apache.org/jira/browse/CASSANDRA-14899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14899:
--
Reviewers: Alex Petrov
> Cannot perform slice reads in reverse direction against tables with
> clustering columns in mixed order
> -
>
> Key: CASSANDRA-14899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14899
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 2.2.x
>
>
> CASSANDRA-11196 accidentally broke reading from tables with mixed clustering
> column order in the opposite direction.
> {{ReversedPrimaryKeyRestrictions::boundsAsComposites}} method attempts to
> reverse the list returned from
> {{PrimaryKeyRestrictionSet::boundsAsComposites}} and fails, as Guava’s
> {{Lists::transform}} method returns a {{List}} that doesn’t support {{set()}}.
> Reproduction:
> {code}
> CREATE TABLE test.test (
> a int,
> b int,
> c int,
> PRIMARY KEY (a, b, c)
> ) WITH CLUSTERING ORDER BY (b ASC, c DESC);
> SELECT * FROM test.test WHERE a = 0 AND (b, c) > (0, 0) ORDER BY b DESC, c
> ASC;
> > ServerError: java.lang.UnsupportedOperationException
> {code}
> {code}
> java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.set(AbstractList.java:132) ~[na:1.8.0_181]
> at java.util.Collections.swap(Collections.java:497) ~[na:1.8.0_181]
> at java.util.Collections.reverse(Collections.java:378) ~[na:1.8.0_181]
> at
> org.apache.cassandra.cql3.restrictions.ReversedPrimaryKeyRestrictions.boundsAsComposites(ReversedPrimaryKeyRestrictions.java:63)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBoundsAsComposites(StatementRestrictions.java:580)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:418)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:359)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:191)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:172)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14899) Cannot perform slice reads in reverse direction against tables with clustering columns in mixed order
[
https://issues.apache.org/jira/browse/CASSANDRA-14899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689343#comment-16689343
]
Aleksey Yeschenko commented on CASSANDRA-14899:
---
Code [here|https://github.com/iamaleksey/cassandra/commits/14899-2.2], CI
[here|https://circleci.com/workflow-run/b6db8bff-2aa2-49e7-8a8e-d01079c85872].
> Cannot perform slice reads in reverse direction against tables with
> clustering columns in mixed order
> -
>
> Key: CASSANDRA-14899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14899
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 2.2.x
>
>
> CASSANDRA-11196 accidentally broke reading from tables with mixed clustering
> column order in the opposite direction.
> {{ReversedPrimaryKeyRestrictions::boundsAsComposites}} method attempts to
> reverse the list returned from
> {{PrimaryKeyRestrictionSet::boundsAsComposites}} and fails, as Guava’s
> {{Lists::transform}} method returns a {{List}} that doesn’t support {{set()}}.
> Reproduction:
> {code}
> CREATE TABLE test.test (
> a int,
> b int,
> c int,
> PRIMARY KEY (a, b, c)
> ) WITH CLUSTERING ORDER BY (b ASC, c DESC);
> SELECT * FROM test.test WHERE a = 0 AND (b, c) > (0, 0) ORDER BY b DESC, c
> ASC;
> > ServerError: java.lang.UnsupportedOperationException
> {code}
> {code}
> java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.set(AbstractList.java:132) ~[na:1.8.0_181]
> at java.util.Collections.swap(Collections.java:497) ~[na:1.8.0_181]
> at java.util.Collections.reverse(Collections.java:378) ~[na:1.8.0_181]
> at
> org.apache.cassandra.cql3.restrictions.ReversedPrimaryKeyRestrictions.boundsAsComposites(ReversedPrimaryKeyRestrictions.java:63)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBoundsAsComposites(StatementRestrictions.java:580)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:418)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:359)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:191)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:172)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14899) Cannot perform slice reads in reverse direction against tables with clustering columns in mixed order
[
https://issues.apache.org/jira/browse/CASSANDRA-14899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14899:
--
Reproduced In: 2.2.13
Since Version: 2.2.6
> Cannot perform slice reads in reverse direction against tables with
> clustering columns in mixed order
> -
>
> Key: CASSANDRA-14899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14899
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 2.2.x
>
>
> CASSANDRA-11196 accidentally broke reading from tables with mixed clustering
> column order in the opposite direction.
> {{ReversedPrimaryKeyRestrictions::boundsAsComposites}} method attempts to
> reverse the list returned from
> {{PrimaryKeyRestrictionSet::boundsAsComposites}} and fails, as Guava’s
> {{Lists::transform}} method returns a {{List}} that doesn’t support {{set()}}.
> Reproduction:
> {code}
> CREATE TABLE test.test (
> a int,
> b int,
> c int,
> PRIMARY KEY (a, b, c)
> ) WITH CLUSTERING ORDER BY (b ASC, c DESC);
> SELECT * FROM test.test WHERE a = 0 AND (b, c) > (0, 0) ORDER BY b DESC, c
> ASC;
> > ServerError: java.lang.UnsupportedOperationException
> {code}
> {code}
> java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.set(AbstractList.java:132) ~[na:1.8.0_181]
> at java.util.Collections.swap(Collections.java:497) ~[na:1.8.0_181]
> at java.util.Collections.reverse(Collections.java:378) ~[na:1.8.0_181]
> at
> org.apache.cassandra.cql3.restrictions.ReversedPrimaryKeyRestrictions.boundsAsComposites(ReversedPrimaryKeyRestrictions.java:63)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBoundsAsComposites(StatementRestrictions.java:580)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:418)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:359)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:191)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:172)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14899) Cannot perform slice reads in reverse direction against tables with clustering columns in mixed order
Aleksey Yeschenko created CASSANDRA-14899:
-
Summary: Cannot perform slice reads in reverse direction against
tables with clustering columns in mixed order
Key: CASSANDRA-14899
URL: https://issues.apache.org/jira/browse/CASSANDRA-14899
Project: Cassandra
Issue Type: Bug
Components: CQL
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Fix For: 2.2.x
CASSANDRA-11196 accidentally broke reading from tables with mixed clustering
column order in the opposite direction.
{{ReversedPrimaryKeyRestrictions::boundsAsComposites}} method attempts to
reverse the list returned from {{PrimaryKeyRestrictionSet::boundsAsComposites}}
and fails, as Guava’s {{Lists::transform}} method returns a {{List}} that
doesn’t support {{set()}}.
Reproduction:
{code}
CREATE TABLE test.test (
a int,
b int,
c int,
PRIMARY KEY (a, b, c)
) WITH CLUSTERING ORDER BY (b ASC, c DESC);
SELECT * FROM test.test WHERE a = 0 AND (b, c) > (0, 0) ORDER BY b DESC, c ASC;
> ServerError: java.lang.UnsupportedOperationException
{code}
{code}
java.lang.UnsupportedOperationException: null
at java.util.AbstractList.set(AbstractList.java:132) ~[na:1.8.0_181]
at java.util.Collections.swap(Collections.java:497) ~[na:1.8.0_181]
at java.util.Collections.reverse(Collections.java:378) ~[na:1.8.0_181]
at
org.apache.cassandra.cql3.restrictions.ReversedPrimaryKeyRestrictions.boundsAsComposites(ReversedPrimaryKeyRestrictions.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBoundsAsComposites(StatementRestrictions.java:580)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.makeFilter(SelectStatement.java:418)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:359)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:191)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:172)
~[main/:na]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14775) StreamingTombstoneHistogramBuilder overflows if > 2B in a single bucket/stabile
[ https://issues.apache.org/jira/browse/CASSANDRA-14775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-14775: - Component/s: (was: Metrics) Compaction > StreamingTombstoneHistogramBuilder overflows if > 2B in a single > bucket/stabile > --- > > Key: CASSANDRA-14775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14775 > Project: Cassandra > Issue Type: Bug > Components: Compaction >Reporter: Benedict >Priority: Major > Fix For: 4.0 > > > This may be unlikely, but is certainly not impossible. In this event, the > count for the bucket will be reset to zero, and the time distorted to 1s in > the future. If MAX_DELETION_TIME were encountered through overflow, this > might result in a bucket with NO_DELETION_TIME. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14892) Possible corruption in compressed files with uncompressed chunks
[ https://issues.apache.org/jira/browse/CASSANDRA-14892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-14892: Assignee: Branimir Lambov Reviewer: Robert Stupp Status: Patch Available (was: Open) > Possible corruption in compressed files with uncompressed chunks > > > Key: CASSANDRA-14892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14892 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Branimir Lambov >Assignee: Branimir Lambov >Priority: Major > > When deciding to switch to writing a chunk uncompressed in a compressed file > (see CASSANDRA-10520) and that chunk is smaller than the full chunk size > (only currently happens in the last chunk of the file), it may very rarely > happen that the chunk is: > - bigger than the compression limit when compressed > - smaller than the compression limit when left uncompressed > If this happens the writer will write it uncompressed, but the reader will > treat it as compressed and fail when attempting to read it. > Such chunks should be padded with 0s to the minimum uncompressed size. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14883) Let Cassandra support the new JVM, Eclipse Openj9.
[ https://issues.apache.org/jira/browse/CASSANDRA-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lee Sangboo updated CASSANDRA-14883: Attachment: jamm-0.3.2.jar > Let Cassandra support the new JVM, Eclipse Openj9. > -- > > Key: CASSANDRA-14883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14883 > Project: Cassandra > Issue Type: Improvement > Components: 4.0, Packaging > Environment: jdk8u192-b12_openj9-0.11.0 > cassandra 4.0.0_beta_20181109_build >Reporter: Lee Sangboo >Priority: Major > Fix For: 4.0.x > > Attachments: jamm-0.3.2.jar, jamm.zip > > > Cassandra does not currently support the new JVM, Eclipse Openj9. In internal > testing, Openj9 outperforms Hotspot. I have deployed a modified jamm library > that has a problem with the current startup, but when I started Cassandra, I > got a log message saying "Non-Oracle JVM detected." Some features, such as > unimported compact SSTables, may not work as intended "If there is no > problem, I would also like to delete the above message. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14883) Let Cassandra support the new JVM, Eclipse Openj9.
[ https://issues.apache.org/jira/browse/CASSANDRA-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lee Sangboo updated CASSANDRA-14883: Attachment: jamm.zip > Let Cassandra support the new JVM, Eclipse Openj9. > -- > > Key: CASSANDRA-14883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14883 > Project: Cassandra > Issue Type: Improvement > Components: 4.0, Packaging > Environment: jdk8u192-b12_openj9-0.11.0 > cassandra 4.0.0_beta_20181109_build >Reporter: Lee Sangboo >Priority: Major > Fix For: 4.0.x > > Attachments: jamm.zip > > > Cassandra does not currently support the new JVM, Eclipse Openj9. In internal > testing, Openj9 outperforms Hotspot. I have deployed a modified jamm library > that has a problem with the current startup, but when I started Cassandra, I > got a log message saying "Non-Oracle JVM detected." Some features, such as > unimported compact SSTables, may not work as intended "If there is no > problem, I would also like to delete the above message. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14883) Let Cassandra support the new JVM, Eclipse Openj9.
[
https://issues.apache.org/jira/browse/CASSANDRA-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689176#comment-16689176
]
Lee Sangboo commented on CASSANDRA-14883:
-
openj9 can edit executable jamm.jar and paste.
{code:java}
// MemoryLayoutSpecification.java 191 line
final String strSpecVersion = System.getProperty("java.specification.version");
final boolean hasDot = strSpecVersion.indexOf('.') != -1;
if (hasDot) {
if ("1".equals(strSpecVersion.substring(0, strSpecVersion.indexOf('.' {
// Java 1.6, 1.7, 1.8
final String strVmVersion = System.getProperty("java.vm.version");
System.out.println("JAMM JAVA VERSION = " + strVmVersion);
if(strVmVersion.startsWith("openj")) {
modernJvm = true;
}else {
final int vmVersion = Integer.parseInt(strVmVersion.substring(0,
strVmVersion.indexOf('.')));
modernJvm = vmVersion >= 17;
};
}
}
{code}
> Let Cassandra support the new JVM, Eclipse Openj9.
> --
>
> Key: CASSANDRA-14883
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14883
> Project: Cassandra
> Issue Type: Improvement
> Components: 4.0, Packaging
> Environment: jdk8u192-b12_openj9-0.11.0
> cassandra 4.0.0_beta_20181109_build
>Reporter: Lee Sangboo
>Priority: Major
> Fix For: 4.0.x
>
> Attachments: jamm-0.3.2.jar, jamm.zip
>
>
> Cassandra does not currently support the new JVM, Eclipse Openj9. In internal
> testing, Openj9 outperforms Hotspot. I have deployed a modified jamm library
> that has a problem with the current startup, but when I started Cassandra, I
> got a log message saying "Non-Oracle JVM detected." Some features, such as
> unimported compact SSTables, may not work as intended "If there is no
> problem, I would also like to delete the above message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14883) Let Cassandra support the new JVM, Eclipse Openj9.
[ https://issues.apache.org/jira/browse/CASSANDRA-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689173#comment-16689173 ] Lee Sangboo commented on CASSANDRA-14883: - jamm.zip uploaded. > Let Cassandra support the new JVM, Eclipse Openj9. > -- > > Key: CASSANDRA-14883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14883 > Project: Cassandra > Issue Type: Improvement > Components: 4.0, Packaging > Environment: jdk8u192-b12_openj9-0.11.0 > cassandra 4.0.0_beta_20181109_build >Reporter: Lee Sangboo >Priority: Major > Fix For: 4.0.x > > Attachments: jamm-0.3.2.jar, jamm.zip > > > Cassandra does not currently support the new JVM, Eclipse Openj9. In internal > testing, Openj9 outperforms Hotspot. I have deployed a modified jamm library > that has a problem with the current startup, but when I started Cassandra, I > got a log message saying "Non-Oracle JVM detected." Some features, such as > unimported compact SSTables, may not work as intended "If there is no > problem, I would also like to delete the above message. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
