[jira] [Assigned] (CASSANDRA-16003) ToolRunner added in CASSANDRA-15942 isn't portable
[
https://issues.apache.org/jira/browse/CASSANDRA-16003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-16003:
---
Assignee: Berenguer Blasi
> ToolRunner added in CASSANDRA-15942 isn't portable
> --
>
> Key: CASSANDRA-16003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16003
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The JVM will output to stderr on some environments to show what flags that
> were picked up, when this happens all tests which validate stderr start to
> fail. This was found in the org.apache.cassandra.tools.ClearSnapshotTest as
> it switched to use the ToolRunner; below is a sample failure on my laptop (I
> had to modify the asserts since they don’t include the input)
> {code}
> java.lang.AssertionError:
> Expecting empty but was:<"Picked up _JAVA_OPTIONS:
> -Djava.net.preferIPv4Stack=true
> ">
> at
> org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:339)
> at
> org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:334)
> at
> org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
> {code}
> Here _JAVA_OPTIONS is used globally on my system so fails the test; there is
> also JAVA_TOOL_RUNNER which is used the same way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168411#comment-17168411 ] Jeremy Hanna commented on CASSANDRA-13701: -- I'm finally getting things going with dtests on a server (after spending hours trying to run them on my laptop). One of the failures with the num_tokens update with bootstrap.py just needed to have a little more time.sleep - from 5 to 10 seconds. I'm going through all of them to see if I can fix them in some way and will then see if I can work with someone to get an updated set of dtests running on the jenkins server. > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Chris Lohfink >Assignee: Jeremy Hanna >Priority: Low > Fix For: 4.0-alpha > > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168404#comment-17168404 ] Berenguer Blasi commented on CASSANDRA-15583: - [~dcapwell] thx for reporting this. I looked into this and it is 'sort of good'. Let me explain: We check stderr now indeed hence we start surfacing these issues. Another similar one I found is that some tests are fine in j8 but on j11 give extra warnings, so these checks makes us aware of these diffs i.e. I am going to look into 16003 > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest, Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). > ||Tool||UX test||UT coverage||dtest coverage||Comments|| > |Nodetool|(x)|(x)|(!)|Deserves it's own ticket. Not all the sub commands are > tested. Dtest also test nodetool as a side effect| > |Cqlsh|(x)|(x)|(!)|Deserves it's own ticket| > |Cassandra-stress|(x)|(x)|(x)|Some UT. Deserves it's own ticket| > |debug-cql|(x)|(x)|(x)|Deserves it's own ticket | > |fqltool|(x)|(/)|(!)|Deserves it's own ticket | > |auditlogviewer|(/)|(!)|(!)|UX tests: C-15991. Docs missing option -i| > |*Sstable utilities*| | | | | > |sstabledump|(/)|(x)|(!)|UX tests: C-15991| > |sstableexpiredblockers|(/)|(x)|(!)|UX tests: C-15991| > |sstablelevelreset|(/)|(x)|(!)|UX tests: C-15991| > |sstableloader|(x)|(x)|(!)|Needs it's own ticket probably| > |sstablemetadata|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, missing options in docs, brittle args parsing| > |sstableofflinerelevel|(/)|(x)|(!)|UX tests: C-15991, brittle args parsing| > |sstablerepairedset|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, brittle args parsing| > |sstablescrub|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs| > |sstablesplit|(/)|(x)|(!)|UX tests: C-15991| > |sstableupgrade|(/)|(x)|(!)|UX tests: C-15991| > |sstableutil|(/)|(x)|(!)|UX tests: C-15991| > |sstableverify|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs + > broken token_range option| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15907:
Test and Documentation Plan:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/commit/e5c3d08a1428d378b6690f0419a2b25724b9736e#diff-bdaab1104a93e723ce0b609a6477c9c4R681],
which have what should be reasonable documentation inline.
There is also a new metric in {{org.apache.cassandra.metrics}}:
{{type=Table}}
{{keyspace=}}
{{scope=}}
{{name=ReplicaFilteringProtectionRowsCachedPerQuery}}
This is a histogram of the number of rows cached per query that activates RFP.
Also, the existing metric, {{ReplicaSideFilteringProtectionRequests}}, is now
called {{ReplicaFilteringProtectionRequests}}.
was:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/commit/e5c3d08a1428d378b6690f0419a2b25724b9736e#diff-bdaab1104a93e723ce0b609a6477c9c4R681],
which have what should be reasonable documentation inline.
There is also a new metric in {{org.apache.cassandra.metrics}}:
{{type=Table}}
{{keyspace=}}
{{scope=}}
{{name=ReplicaFilteringProtectionRowsCachedPerQuery}}
This is a histogram of the number of rows cached per query that activates RFP.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15907:
Test and Documentation Plan:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/commit/e5c3d08a1428d378b6690f0419a2b25724b9736e#diff-bdaab1104a93e723ce0b609a6477c9c4R681],
which have what should be reasonable documentation inline.
There is also a new metric in {{org.apache.cassandra.metrics}}:
{{type=Table}}
{{keyspace=}}
{{scope=}}
{{name=ReplicaFilteringProtectionRowsCachedPerQuery}}
This is a histogram of the number of rows cached per query that activates RFP.
was:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/pull/659/files?file-filters%5B%5D=.java&file-filters%5B%5D=.xml&file-filters%5B%5D=.yaml#diff-bdaab1104a93e723ce0b609a6477c9c4R664],
which have what should be reasonable documentation inline.
There is also a new metric in {{org.apache.cassandra.metrics}}:
{{type=Table}}
{{keyspace=}}
{{scope=}}
{{name=ReplicaFilteringProtectionRowsCachedPerQuery}}
This is a histogram of the number of rows cached per query that activates RFP.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16002:
--
Fix Version/s: (was: 4.0-beta)
(was: 3.11.x)
(was: 3.0.x)
4.0-beta2
3.11.8
3.0.22
Since Version: 3.0.21
Source Control Link:
https://github.com/apache/cassandra/commit/624d01660bdad4dc924717f4c602ce6241c0c825
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
CI results
3.0:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/395/workflows/8bd01d34-7280-4176-8b31-180d193e8125
3.11:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/396/workflows/cbba3a88-3371-47b6-9100-1e806efa6ce5
trunk:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/397/workflows/89e13b1f-6395-4a7e-a16c-0d33497dd7c4
there are failing tests, but they are known flaky.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.l
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 8957c08f1999033d7b747d0567b0f021c667d5d9
Merge: e318841 624d016
Author: David Capwell
AuthorDate: Thu Jul 30 19:25:28 2020 -0700
Merge branch 'cassandra-3.0' into cassandra-3.11
src/java/org/apache/cassandra/io/util/FileUtils.java | 2 +-
test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --cc src/java/org/apache/cassandra/io/util/FileUtils.java
index 30a0b0e,5a21729..e1fd380
--- a/src/java/org/apache/cassandra/io/util/FileUtils.java
+++ b/src/java/org/apache/cassandra/io/util/FileUtils.java
@@@ -77,10 -75,10 +77,10 @@@ public final class FileUtil
}
catch (Throwable t)
{
+ logger.error("Cannot initialize un-mmaper. (Are you using a
non-Oracle JVM?) Compacted data files will not be removed promptly. Consider
using an Oracle JVM or using standard disk access mode", t);
JVMStabilityInspector.inspectThrowable(t);
- logger.info("Cannot initialize un-mmaper. (Are you using a
non-Oracle JVM?) Compacted data files will not be removed promptly. Consider
using an Oracle JVM or using standard disk access mode");
}
-canCleanDirectBuffers = canClean;
+isCleanerAvailable = canClean;
}
public static void createHardLink(String from, String to)
diff --cc test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 19cb2a0,95fefd2..ac20e84
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@@ -467,7 -511,8 +465,8 @@@ public class Instance extends IsolatedE
assert
config.networkTopology().contains(config.broadcastAddress());
DistributedTestSnitch.assign(config.networkTopology());
-DatabaseDescriptor.setDaemonInitialized();
+DatabaseDescriptor.daemonInitialization();
+ FileUtils.setFSErrorHandler(new DefaultFSErrorHandler());
DatabaseDescriptor.createAllDirectories();
// We need to persist this as soon as possible after startup
checks.
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (e318841 -> 8957c08)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e318841 ninja fix failure in DatabaseDescriptorRefTest new 624d016 jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils new 8957c08 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/java/org/apache/cassandra/io/util/FileUtils.java | 2 +- test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (7e6f491 -> c76dda9)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 7e6f491 Merge branch 'cassandra-3.11' into trunk new 624d016 jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils new 8957c08 Merge branch 'cassandra-3.0' into cassandra-3.11 new c76dda9 Merge branch 'cassandra-3.11' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/java/org/apache/cassandra/io/util/FileUtils.java | 4 ++-- test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit c76dda93770663c4fe06c05c5ef90b354f8dbc96
Merge: 7e6f491 8957c08
Author: David Capwell
AuthorDate: Thu Jul 30 19:26:25 2020 -0700
Merge branch 'cassandra-3.11' into trunk
src/java/org/apache/cassandra/io/util/FileUtils.java | 4 ++--
test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --cc src/java/org/apache/cassandra/io/util/FileUtils.java
index cf61277,e1fd380..7c940c5
--- a/src/java/org/apache/cassandra/io/util/FileUtils.java
+++ b/src/java/org/apache/cassandra/io/util/FileUtils.java
@@@ -68,39 -63,24 +68,39 @@@ public final class FileUtil
public static final long ONE_TB = 1024 * ONE_GB;
private static final DecimalFormat df = new DecimalFormat("#.##");
-public static final boolean isCleanerAvailable;
private static final AtomicReference>
fsErrorHandler = new AtomicReference<>(Optional.empty());
+private static Class clsDirectBuffer;
+private static MethodHandle mhDirectBufferCleaner;
+private static MethodHandle mhCleanerClean;
+
static
{
-boolean canClean = false;
try
{
+clsDirectBuffer = Class.forName("sun.nio.ch.DirectBuffer");
+Method mDirectBufferCleaner =
clsDirectBuffer.getMethod("cleaner");
+mhDirectBufferCleaner =
MethodHandles.lookup().unreflect(mDirectBufferCleaner);
+Method mCleanerClean =
mDirectBufferCleaner.getReturnType().getMethod("clean");
+mhCleanerClean = MethodHandles.lookup().unreflect(mCleanerClean);
+
ByteBuffer buf = ByteBuffer.allocateDirect(1);
-((DirectBuffer) buf).cleaner().clean();
-canClean = true;
+clean(buf);
+}
+catch (IllegalAccessException e)
+{
+logger.error("FATAL: Cassandra is unable to access required
classes. This usually means it has been " +
+"run without the aid of the standard startup scripts or the
scripts have been edited. If this was " +
+"intentional, and you are attempting to use Java 11+ you may
need to add the --add-exports and " +
- "--add-opens jvm options from either jvm11-server.options or
jvm11-client.options");
++"--add-opens jvm options from either jvm11-server.options or
jvm11-client.options", e);
+throw new RuntimeException(e); // causes
ExceptionInInitializerError, will prevent startup
}
catch (Throwable t)
{
- logger.error("FATAL: Cannot initialize optimized memory
deallocator.");
-logger.error("Cannot initialize un-mmaper. (Are you using a
non-Oracle JVM?) Compacted data files will not be removed promptly. Consider
using an Oracle JVM or using standard disk access mode", t);
++logger.error("FATAL: Cannot initialize optimized memory
deallocator.", t);
JVMStabilityInspector.inspectThrowable(t);
+throw new RuntimeException(t); // causes
ExceptionInInitializerError, will prevent startup
}
-isCleanerAvailable = canClean;
}
public static void createHardLink(String from, String to)
diff --cc test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 989bf6e,ac20e84..44cef6f
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@@ -337,30 -460,19 +337,29 @@@ public class Instance extends IsolatedE
sync(() -> {
try
{
- FileUtils.setFSErrorHandler(new DefaultFSErrorHandler());
-
+if (config.has(GOSSIP))
+{
+// TODO: hacky
+System.setProperty("cassandra.ring_delay_ms", "5000");
+System.setProperty("cassandra.consistent.rangemovement",
"false");
+
System.setProperty("cassandra.consistent.simultaneousmoves.allow", "true");
+}
+
mkdirs();
-assert
config.networkTopology().contains(config.broadcastAddress());
+assert
config.networkTopology().contains(config.broadcastAddress()) :
String.format("Network topology %s doesn't contain the address %s",
+
config.networkTopology(), config.broadcastAddress());
DistributedTestSnitch.assign(config.networkTopology());
DatabaseDescriptor.daemonInitialization();
+ FileUtils.setFSErrorHandler(new DefaultFSErrorHandler());
DatabaseDescriptor.createAllD
[cassandra] branch cassandra-3.0 updated: jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 624d016 jvm upgrade dtests fail on java 11 caused by bad
initialization order of DatabaseDescriptor and FileUtils
624d016 is described below
commit 624d01660bdad4dc924717f4c602ce6241c0c825
Author: David Capwell
AuthorDate: Thu Jul 30 17:02:05 2020 -0700
jvm upgrade dtests fail on java 11 caused by bad initialization order of
DatabaseDescriptor and FileUtils
patch by David Capwell; reviewed by Jon Meredith, Jordan West for
CASSANDRA-16002
---
src/java/org/apache/cassandra/io/util/FileUtils.java | 2 +-
test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/io/util/FileUtils.java
b/src/java/org/apache/cassandra/io/util/FileUtils.java
index 191e965..5a21729 100644
--- a/src/java/org/apache/cassandra/io/util/FileUtils.java
+++ b/src/java/org/apache/cassandra/io/util/FileUtils.java
@@ -75,8 +75,8 @@ public final class FileUtils
}
catch (Throwable t)
{
+logger.error("Cannot initialize un-mmaper. (Are you using a
non-Oracle JVM?) Compacted data files will not be removed promptly. Consider
using an Oracle JVM or using standard disk access mode", t);
JVMStabilityInspector.inspectThrowable(t);
-logger.info("Cannot initialize un-mmaper. (Are you using a
non-Oracle JVM?) Compacted data files will not be removed promptly. Consider
using an Oracle JVM or using standard disk access mode");
}
canCleanDirectBuffers = canClean;
}
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 8fa5966..95fefd2 100644
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@ -506,14 +506,13 @@ public class Instance extends IsolatedExecutor implements
IInvokableInstance
sync(() -> {
try
{
-FileUtils.setFSErrorHandler(new DefaultFSErrorHandler());
-
mkdirs();
assert
config.networkTopology().contains(config.broadcastAddress());
DistributedTestSnitch.assign(config.networkTopology());
DatabaseDescriptor.setDaemonInitialized();
+FileUtils.setFSErrorHandler(new DefaultFSErrorHandler());
DatabaseDescriptor.createAllDirectories();
// We need to persist this as soon as possible after startup
checks.
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16002:
--
Status: Ready to Commit (was: Review In Progress)
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM or using standard disk access mode");
> }
> canCleanDirectBuffers = canClean;
> }
> {code}
> JVMStabilityInspector will check the throwable which will eventually call
> org.apache.cassandra.config.DatabaseDescriptor#getDiskFailureP
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168325#comment-17168325
]
David Capwell commented on CASSANDRA-16002:
---
CI having issues with CASSANDRA-16004, I am trying to work around it to get a
working build.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM or using standard disk access mode");
> }
> canCleanDirectBuffers = canClean;
> }
> {code}
> JVMStabilityInspector will check the throw
[jira] [Commented] (CASSANDRA-15971) full query log needs improvement
[
https://issues.apache.org/jira/browse/CASSANDRA-15971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168324#comment-17168324
]
Lorina Poland commented on CASSANDRA-15971:
---
[https://github.com/apache/cassandra/pull/705] is available for review.
> full query log needs improvement
>
>
> Key: CASSANDRA-15971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15971
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website, Tool/fql
>Reporter: Jonathan Shook
>Assignee: Lorina Poland
>Priority: Normal
> Attachments: st1.txt
>
>
> When trying out full query logging as a possible integration for nosqlbench
> usage, I ran across many issues which would make it painful for users. Since
> there were several, they will be added to a single issue for now. This issue
> can be broken up if needed.
>
> FQL doesn't work on my system, even though it says it is logging queries.
> With the following configuration in cassandra.yaml:
>
> {noformat}
> full_query_logging_options:
> log_dir: /REDACTED/fullquerylogs
> roll_cycle: HOURLY
> block: true
> max_queue_weight: 268435456 # 256 MiB
> max_log_size: 17179869184 # 16 GiB
> ## archive command is "/path/to/script.sh %path" where %path is replaced
> with the file being rolled:
> # archive_command:
> # max_archive_retries: 10
> {noformat}
> which appears to be the minimal configuration needed to enable fql, only a
> single file `directory-listing.cq4t` is created, which is a 64K sized file of
> zeroes.
>
>
> Calling bin/nodetool enablefullquerylog throws an error initially.
> [jshook@cass4 bin]$ ./nodetool enablefullquerylog
>
> {noformat}
> error: sun.nio.ch.FileChannelImpl.map0(int,long,long)
> -- StackTrace --
> java.lang.NoSuchMethodException:
> sun.nio.ch.FileChannelImpl.map0(int,long,long)
> at java.base/java.lang.Class.getDeclaredMethod(Class.java:2553)
> at net.openhft.chronicle.core.OS.lambda$static$0(OS.java:51)
> at
> net.openhft.chronicle.core.ClassLocal.computeValue(ClassLocal.java:53){noformat}
> (full stack trace attached to this ticket)
>
> Subsequent calls produce normal output:
>
> {noformat}
> [jshook@cass4 c4b1]$ bin/nodetool enablefullquerylog
> nodetool: Already logging to /home/jshook/c4b1/data/fullquerylogs
> See 'nodetool help' or 'nodetool help '.{noformat}
>
>
> nodetool missing getfullquerylog makes it difficult to verify current
> fullquerylog state without changing it. The conventions for nodetool commands
> should be followed to avoid confusing users.
>
> (maybe)
> {noformat}
> tools/bin/fqltool help{noformat}
> should print out help for all fqltool commands rather than simply repeating
> the default The most commonly used fqltool commands are..
>
> [https://cassandra.apache.org/doc/latest/new/fqllogging.html] is
> malformatted, mixing the appearance of configuration with comments, which is
> confusing at best.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16005) sstableloader cannot parse schema of tables with CQL duration type
[
https://issues.apache.org/jira/browse/CASSANDRA-16005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16005:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Normal
Component/s: Tool/bulk load
Discovered By: User Report
Fix Version/s: 3.11.x
Severity: Normal
Status: Open (was: Triage Needed)
> sstableloader cannot parse schema of tables with CQL duration type
> --
>
> Key: CASSANDRA-16005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16005
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erick Ramirez
>Priority: Normal
> Fix For: 3.11.x
>
>
> h2. Symptom
> A user reported issues bulk loading data with {{sstableloader}} on C* 3.11
> for a table with columns of type {{duration}}:
> {noformat}
> ERROR 17:38:10,726 Error parsing schema for table datakeyspace.retrylog:
> Cluster.getMetadata().getKeyspace("datakeyspace").getTable("retrylog") will
> be missing or incomplete
> com.datastax.driver.core.exceptions.UnresolvedUserTypeException: Cannot
> resolve user type datakeyspace.duration
> at
> com.datastax.driver.core.DataTypeCqlNameParser.parse(DataTypeCqlNameParser.java:147)
> ~[cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.TableMetadata.build(TableMetadata.java:188)
> ~[cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.SchemaParser.buildTables(SchemaParser.java:176)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.SchemaParser.buildKeyspaces(SchemaParser.java:128)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.SchemaParser.refresh(SchemaParser.java:64)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:343)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:273)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1424)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at com.datastax.driver.core.Cluster.init(Cluster.java:163)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:334)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:309)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at com.datastax.driver.core.Cluster.connect(Cluster.java:251)
> [cassandra-driver-core-3.0.1-shaded.jar:na]
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:73)
> [apache-cassandra-3.11.3.jar:3.11.3]
> {noformat}
> h2. Cause
> Support for {{duration}} type was added to Java driver 3.2.0
> ([JAVA-1347|https://datastax-oss.atlassian.net/browse/JAVA-1347]). The shaded
> driver included in Cassandra 3.11 is old and does support the {{duration}}
> type:
> {noformat}
> lib/cassandra-driver-core-3.0.1-shaded.jar
> {noformat}
> h2. Workaround
> *Step 1* - Download a newer version of the Java driver from Maven in the same
> 3.x family. For example:
> https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core/3.10.0
> *Step 2* - Swap out the old JAR with
> {{cassandra-driver-core-3.10.0-shaded.jar}}.
> *Step 3* - Re-run {{sstableloader}}.
> h2. Solution
> I recommend we update the Java driver version in the next patch release of C*
> 3.11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16005) sstableloader cannot parse schema of tables with CQL duration type
Erick Ramirez created CASSANDRA-16005:
-
Summary: sstableloader cannot parse schema of tables with CQL
duration type
Key: CASSANDRA-16005
URL: https://issues.apache.org/jira/browse/CASSANDRA-16005
Project: Cassandra
Issue Type: Bug
Reporter: Erick Ramirez
h2. Symptom
A user reported issues bulk loading data with {{sstableloader}} on C* 3.11 for
a table with columns of type {{duration}}:
{noformat}
ERROR 17:38:10,726 Error parsing schema for table datakeyspace.retrylog:
Cluster.getMetadata().getKeyspace("datakeyspace").getTable("retrylog") will be
missing or incomplete
com.datastax.driver.core.exceptions.UnresolvedUserTypeException: Cannot resolve
user type datakeyspace.duration
at
com.datastax.driver.core.DataTypeCqlNameParser.parse(DataTypeCqlNameParser.java:147)
~[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.TableMetadata.build(TableMetadata.java:188)
~[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.SchemaParser.buildTables(SchemaParser.java:176)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.SchemaParser.buildKeyspaces(SchemaParser.java:128)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.SchemaParser.refresh(SchemaParser.java:64)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:343)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:273)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:201)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:79)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1424)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.Cluster.init(Cluster.java:163)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:334)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:309)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at com.datastax.driver.core.Cluster.connect(Cluster.java:251)
[cassandra-driver-core-3.0.1-shaded.jar:na]
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:73)
[apache-cassandra-3.11.3.jar:3.11.3]
{noformat}
h2. Cause
Support for {{duration}} type was added to Java driver 3.2.0
([JAVA-1347|https://datastax-oss.atlassian.net/browse/JAVA-1347]). The shaded
driver included in Cassandra 3.11 is old and does support the {{duration}} type:
{noformat}
lib/cassandra-driver-core-3.0.1-shaded.jar
{noformat}
h2. Workaround
*Step 1* - Download a newer version of the Java driver from Maven in the same
3.x family. For example:
https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core/3.10.0
*Step 2* - Swap out the old JAR with
{{cassandra-driver-core-3.10.0-shaded.jar}}.
*Step 3* - Re-run {{sstableloader}}.
h2. Solution
I recommend we update the Java driver version in the next patch release of C*
3.11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168321#comment-17168321
]
Jon Meredith commented on CASSANDRA-16002:
--
LGTM. Code changes make sense. We should probably update the wording on the
JVM selection, but that's unrelated to this ticket.
Locally ran the branches through the in-jvm Dtest upgrades and checked trunk
passed on J8 and failed on J11 before the patch and all test pass afterwards.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be rem
[jira] [Updated] (CASSANDRA-16004) When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect this and will use the jars from the older version
[
https://issues.apache.org/jira/browse/CASSANDRA-16004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16004:
--
Description:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/389/workflows/ea7776ac-5be0-4cb4-ab4c-61f524397c07/jobs/2019
{code}
build-test:
[javac] Compiling 510 source files to
/home/cassandra/cassandra/build/test/classes
[javac] warning: Supported source version 'RELEASE_6' from annotation
processor 'org.openjdk.jmh.generators.BenchmarkProcessor' less than -source
'1.8'
[javac]
/home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java:49:
error: no suitable constructor found for
SimpleQueryResult(String[],Object[][],warnings =[...]nings)
[javac] return new SimpleQueryResult(names, results, warnings
== null ? Collections.emptyList() : warnings);
[javac]^
[javac] constructor
SimpleQueryResult.SimpleQueryResult(String[],Object[][]) is not applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor
SimpleQueryResult.SimpleQueryResult(String[],Object[][],Predicate,int) is
not applicable
[javac] (actual and formal argument lists differ in length)
[javac]
/home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java:212:
error: cannot find symbol
[javac] List futureWarnings = futureResult.warnings();
[javac] ^
[javac] symbol: method warnings()
[javac] location: variable futureResult of type SimpleQueryResult
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
[javac] 1 warning
BUILD FAILED
/home/cassandra/cassandra/build.xml:1176: Compile failed; see the compiler
error output for details.
{code}
cassandra-3.0 compiled against the dtest jar provided by cassandra-2.2, so
failed.
was:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/389/workflows/ea7776ac-5be0-4cb4-ab4c-61f524397c07/jobs/2019
build-test:
[javac] Compiling 510 source files to
/home/cassandra/cassandra/build/test/classes
[javac] warning: Supported source version 'RELEASE_6' from annotation
processor 'org.openjdk.jmh.generators.BenchmarkProcessor' less than -source
'1.8'
[javac]
/home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java:49:
error: no suitable constructor found for
SimpleQueryResult(String[],Object[][],warnings =[...]nings)
[javac] return new SimpleQueryResult(names, results, warnings
== null ? Collections.emptyList() : warnings);
[javac]^
[javac] constructor
SimpleQueryResult.SimpleQueryResult(String[],Object[][]) is not applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor
SimpleQueryResult.SimpleQueryResult(String[],Object[][],Predicate,int) is
not applicable
[javac] (actual and formal argument lists differ in length)
[javac]
/home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java:212:
error: cannot find symbol
[javac] List futureWarnings = futureResult.warnings();
[javac] ^
[javac] symbol: method warnings()
[javac] location: variable futureResult of type SimpleQueryResult
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
[javac] 1 warning
BUILD FAILED
/home/cassandra/cassandra/build.xml:1176: Compile failed; see the compiler
error output for details.
cassandra-3.0 compiled against the dtest jar provided by cassandra-2.2, so
failed.
> When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect
> this and will use the jars from the older version
>
>
> Key: CASSANDRA-16004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16004
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> https://app.circleci.com/pipelines/github/dcapwell/
[jira] [Commented] (CASSANDRA-15980) Improve log messages for socket connection/disconnection
[
https://issues.apache.org/jira/browse/CASSANDRA-15980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168316#comment-17168316
]
Jon Meredith commented on CASSANDRA-15980:
--
Thanks for the review, I've fixed the NPE you found and explained that I
updated the message with the type of connection.
> Improve log messages for socket connection/disconnection
>
>
> Key: CASSANDRA-15980
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15980
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Logging for inbound SSL connections can take place before protocol
> negotiation has taken place and logs a misleading cipher that could cause
> problems for security auditing.
>
>
> {code:java}
> INFO 2020-07-03T13:57:58,380 [Messaging-EventLoop-3-1]
> org.apache.cassandra.net.InboundConnectionInitiator:242 - connection from
> peer /1.1.1.1:57899 to /2.2.2.2:7000, protocol = TLSv1.2, cipher suite =
> SSL_NULL_WITH_NULL_NULL
> {code}
>
> Instead Cassandra should log the connection & protocol, then once the cipher
> has been negotiated log the agreed upon cipher.
>
>
> If the inbound SSL connection does not present a client certificate,
> Cassandra logs this error, even if the client wasn't required to.
> {code:java}
> ERROR 2020-07-14T11:58:45,925 [Native-Transport-Requests-1]
> org.apache.cassandra.transport.ServerConnection:140 - Failed to get peer
> certificates for peer /4.3.2.1:59263
> {code}
>
> Logging the absense of verified certificates should be a concern of the
> SaslNegotiator if it requires it, and not something worth alerting the
> operator for generally. Downgrade to debug message to make investigation
> possible if needed.
>
>
> Finally, to help with logging issues related to disconnection, add a log
> statement when an instance decides it no longer needs to keep a gossip
> connection open when cleaning up connections in
> org.apache.cassandra.net.OutboundConnections.UnusedConnectionMonitor#closeUnusedSinceLastRun
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16004) When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect this and will use the jars from the older version
[ https://issues.apache.org/jira/browse/CASSANDRA-16004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16004: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Low Hanging Fruit Discovered By: Unit Test Fix Version/s: 4.0-beta 3.11.x 3.0.x Severity: Normal Status: Open (was: Triage Needed) > When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect > this and will use the jars from the older version > > > Key: CASSANDRA-16004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16004 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > https://app.circleci.com/pipelines/github/dcapwell/cassandra/389/workflows/ea7776ac-5be0-4cb4-ab4c-61f524397c07/jobs/2019 > build-test: > [javac] Compiling 510 source files to > /home/cassandra/cassandra/build/test/classes > [javac] warning: Supported source version 'RELEASE_6' from annotation > processor 'org.openjdk.jmh.generators.BenchmarkProcessor' less than -source > '1.8' > [javac] > /home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java:49: > error: no suitable constructor found for > SimpleQueryResult(String[],Object[][],warnings =[...]nings) > [javac] return new SimpleQueryResult(names, results, warnings > == null ? Collections.emptyList() : warnings); > [javac]^ > [javac] constructor > SimpleQueryResult.SimpleQueryResult(String[],Object[][]) is not applicable > [javac] (actual and formal argument lists differ in length) > [javac] constructor > SimpleQueryResult.SimpleQueryResult(String[],Object[][],Predicate,int) > is not applicable > [javac] (actual and formal argument lists differ in length) > [javac] > /home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java:212: > error: cannot find symbol > [javac] List futureWarnings = futureResult.warnings(); > [javac] ^ > [javac] symbol: method warnings() > [javac] location: variable futureResult of type SimpleQueryResult > [javac] Note: Some input files use or override a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [javac] 2 errors > [javac] 1 warning > BUILD FAILED > /home/cassandra/cassandra/build.xml:1176: Compile failed; see the compiler > error output for details. > cassandra-3.0 compiled against the dtest jar provided by cassandra-2.2, so > failed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-15937:
-
Comment: was deleted
(was: Thanks for the review, I've fixed the NPE you found.)
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16004) When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect this and will use the jars from the older version
David Capwell created CASSANDRA-16004: - Summary: When jvm dtest apis differ Circle CI's dtest_jars_build can fail to detect this and will use the jars from the older version Key: CASSANDRA-16004 URL: https://issues.apache.org/jira/browse/CASSANDRA-16004 Project: Cassandra Issue Type: Bug Components: Build Reporter: David Capwell Assignee: David Capwell https://app.circleci.com/pipelines/github/dcapwell/cassandra/389/workflows/ea7776ac-5be0-4cb4-ab4c-61f524397c07/jobs/2019 build-test: [javac] Compiling 510 source files to /home/cassandra/cassandra/build/test/classes [javac] warning: Supported source version 'RELEASE_6' from annotation processor 'org.openjdk.jmh.generators.BenchmarkProcessor' less than -source '1.8' [javac] /home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/impl/RowUtil.java:49: error: no suitable constructor found for SimpleQueryResult(String[],Object[][],warnings =[...]nings) [javac] return new SimpleQueryResult(names, results, warnings == null ? Collections.emptyList() : warnings); [javac]^ [javac] constructor SimpleQueryResult.SimpleQueryResult(String[],Object[][]) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor SimpleQueryResult.SimpleQueryResult(String[],Object[][],Predicate,int) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/cassandra/cassandra/test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java:212: error: cannot find symbol [javac] List futureWarnings = futureResult.warnings(); [javac] ^ [javac] symbol: method warnings() [javac] location: variable futureResult of type SimpleQueryResult [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 2 errors [javac] 1 warning BUILD FAILED /home/cassandra/cassandra/build.xml:1176: Compile failed; see the compiler error output for details. cassandra-3.0 compiled against the dtest jar provided by cassandra-2.2, so failed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168315#comment-17168315
]
Jon Meredith commented on CASSANDRA-15937:
--
Thanks for the review, I've fixed the NPE you found.
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15937:
--
Test and Documentation Plan: tests
Status: Patch Available (was: In Progress)
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15937:
--
Reviewers: David Capwell, David Capwell (was: David Capwell)
David Capwell, David Capwell
Status: Review In Progress (was: Patch Available)
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16002:
--
Reviewers: Jon Meredith, Jordan West (was: Jordan West)
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM or using standard disk access mode");
> }
> canCleanDirectBuffers = canClean;
> }
> {code}
> JVMStabilityInspector will check the throwable which will eventually call
> org.apache.cassandra.config.DatabaseDescriptor#getDiskFa
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168291#comment-17168291
]
David Capwell commented on CASSANDRA-16002:
---
To help with review, the following commands can be run locally
{code}
setjdk 8
unset CASSANDRA_USE_JDK11
for v in 2.2 3.0 3.11 trunk; do
cd ../cassandra-$v
ant realclean
ant jar dtest-jar
ant generate-idea-files
done
echo ../cassandra-{3.0,3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-2.2/build/dtest-2.2*.jar
echo ../cassandra-{3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-3.0/build/dtest-3.0*.jar
echo ../cassandra-trunk/build/ | xargs -n1 cp -v
../cassandra-3.11/build/dtest-3.11*.jar
cd ../cassandra-trunk
setjdk 11
ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> s
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168291#comment-17168291
]
David Capwell edited comment on CASSANDRA-16002 at 7/30/20, 11:19 PM:
--
To help with review, the following commands can be run locally
{code}
setjdk 8
unset CASSANDRA_USE_JDK11
for v in 2.2 3.0 3.11 trunk; do
cd ../cassandra-$v
ant realclean
ant jar dtest-jar
ant generate-idea-files
done
echo ../cassandra-{3.0,3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-2.2/build/dtest-2.2*.jar
echo ../cassandra-{3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-3.0/build/dtest-3.0*.jar
echo ../cassandra-trunk/build/ | xargs -n1 cp -v
../cassandra-3.11/build/dtest-3.11*.jar
cd ../cassandra-trunk
setjdk 11
CASSANDRA_USE_JDK11=true ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
{code}
was (Author: dcapwell):
To help with review, the following commands can be run locally
{code}
setjdk 8
unset CASSANDRA_USE_JDK11
for v in 2.2 3.0 3.11 trunk; do
cd ../cassandra-$v
ant realclean
ant jar dtest-jar
ant generate-idea-files
done
echo ../cassandra-{3.0,3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-2.2/build/dtest-2.2*.jar
echo ../cassandra-{3.11,trunk}/build/ | xargs -n1 cp -v
../cassandra-3.0/build/dtest-3.0*.jar
echo ../cassandra-trunk/build/ | xargs -n1 cp -v
../cassandra-3.11/build/dtest-3.11*.jar
cd ../cassandra-trunk
setjdk 11
ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(Distrib
[jira] [Updated] (CASSANDRA-15980) Improve log messages for socket connection/disconnection
[
https://issues.apache.org/jira/browse/CASSANDRA-15980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15980:
--
Reviewers: Aleksey Yeschenko, David Capwell (was: Aleksey Yeschenko)
> Improve log messages for socket connection/disconnection
>
>
> Key: CASSANDRA-15980
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15980
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Logging for inbound SSL connections can take place before protocol
> negotiation has taken place and logs a misleading cipher that could cause
> problems for security auditing.
>
>
> {code:java}
> INFO 2020-07-03T13:57:58,380 [Messaging-EventLoop-3-1]
> org.apache.cassandra.net.InboundConnectionInitiator:242 - connection from
> peer /1.1.1.1:57899 to /2.2.2.2:7000, protocol = TLSv1.2, cipher suite =
> SSL_NULL_WITH_NULL_NULL
> {code}
>
> Instead Cassandra should log the connection & protocol, then once the cipher
> has been negotiated log the agreed upon cipher.
>
>
> If the inbound SSL connection does not present a client certificate,
> Cassandra logs this error, even if the client wasn't required to.
> {code:java}
> ERROR 2020-07-14T11:58:45,925 [Native-Transport-Requests-1]
> org.apache.cassandra.transport.ServerConnection:140 - Failed to get peer
> certificates for peer /4.3.2.1:59263
> {code}
>
> Logging the absense of verified certificates should be a concern of the
> SaslNegotiator if it requires it, and not something worth alerting the
> operator for generally. Downgrade to debug message to make investigation
> possible if needed.
>
>
> Finally, to help with logging issues related to disconnection, add a log
> statement when an instance decides it no longer needs to keep a gossip
> connection open when cleaning up connections in
> org.apache.cassandra.net.OutboundConnections.UnusedConnectionMonitor#closeUnusedSinceLastRun
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15980) Improve log messages for socket connection/disconnection
[
https://issues.apache.org/jira/browse/CASSANDRA-15980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168290#comment-17168290
]
David Capwell commented on CASSANDRA-15980:
---
Sorry for the delay, been trying to validate.
In 3.11 I don't see any of these logs, so this is local to 4.0 and wouldn't
regress our logging.
It took a bit to replicate the issue, as the document linked from Nate doesn't
cause these logs to happen; in fact ssl doesn't happen (is this a known issue?).
Here are the steps I took to replicate
{code}
Based off
https://thelastpickle.com/blog/2015/09/30/hardening-cassandra-step-by-step-part-1-server-to-server.html
```
# create non-ssl cluster
ccm create -n 3 -v 3.11.6 sslverify-311
```
Setup the certs
```
cat < gen_ca_cert.conf
[ req ]
distinguished_name = req_distinguished_name
prompt = no
output_password= mypass
default_bits = 2048
[ req_distinguished_name ]
C = US
ST = TX
L = Austin
O = TLP
OU = TestCluster
CN = TestClusterMasterCA
emailAddress = i...@thelastpickle.com
EOF
openssl req -config gen_ca_cert.conf -new -x509 -keyout ca-key -out ca-cert
-days 365
# should now have ca-cert and ca-key
# validate they work
openssl x509 -in ca-cert -text -noout
# setup the public/private keys
setjdk 8
keytool -genkeypair -keyalg RSA -alias node1 -keystore
node1-server-keystore.jks -storepass awesomekeypass -keypass awesomekeypass
-validity 365 -keysize 2048 -dname "CN=node1, OU=SSL-verification-cluster,
O=TheLastPickle, C=US"
keytool -genkeypair -keyalg RSA -alias node2 -keystore
node2-server-keystore.jks -storepass awesomekeypass -keypass awesomekeypass
-validity 365 -keysize 2048 -dname "CN=node2, OU=SSL-verification-cluster,
O=TheLastPickle, C=US"
keytool -genkeypair -keyalg RSA -alias node3 -keystore
node3-server-keystore.jks -storepass awesomekeypass -keypass awesomekeypass
-validity 365 -keysize 2048 -dname "CN=node3, OU=SSL-verification-cluster,
O=TheLastPickle, C=US"
# should now have node1-server-keystore.jks node2-server-keystore.jks and
node3-server-keystore.jks
# validate they work
keytool -list -v -keystore node1-server-keystore.jks -storepass awesomekeypass
keytool -keystore node1-server-keystore.jks -alias node1 -certreq -file
node1_cert_sr -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node2-server-keystore.jks -alias node2 -certreq -file
node2_cert_sr -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node3-server-keystore.jks -alias node3 -certreq -file
node3_cert_sr -keypass awesomekeypass -storepass awesomekeypass
# should now have node1_cert_sr and node2_cert_sr node3_cert_sr
# sign
openssl x509 -req -CA ca-cert -CAkey ca-key -in node1_cert_sr -out
node1_cert_signed -days 365 -CAcreateserial -passin pass:mypass
openssl x509 -req -CA ca-cert -CAkey ca-key -in node2_cert_sr -out
node2_cert_signed -days 365 -CAcreateserial -passin pass:mypass
openssl x509 -req -CA ca-cert -CAkey ca-key -in node3_cert_sr -out
node3_cert_signed -days 365 -CAcreateserial -passin pass:mypass
should have node1_cert_signed node2_cert_signed node3_cert_signed and
ca-cert.srl
# add to key store
keytool -keystore node1-server-keystore.jks -alias CARoot -import -file ca-cert
-noprompt -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node2-server-keystore.jks -alias CARoot -import -file ca-cert
-noprompt -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node3-server-keystore.jks -alias CARoot -import -file ca-cert
-noprompt -keypass awesomekeypass -storepass awesomekeypass
should have node1-server-keystore.jks node2-server-keystore.jks and
node3-server-keystore.jks
keytool -keystore node1-server-keystore.jks -alias node1 -import -file
node1_cert_signed -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node2-server-keystore.jks -alias node2 -import -file
node2_cert_signed -keypass awesomekeypass -storepass awesomekeypass
keytool -keystore node3-server-keystore.jks -alias node3 -import -file
node3_cert_signed -keypass awesomekeypass -storepass awesomekeypass
# Build the trust store
keytool -keystore generic-server-truststore.jks -alias CARoot -importcert -file
ca-cert -keypass mypass -storepass truststorepass -noprompt
# should have generic-server-truststore.jks
```
```
ccm create -n 3 sslverify-trunk
--install-dir=$HOME/src/github/apache/cassandra-trunk
cluster="sslverify-trunk"
cp node1-server-keystore.jks ~/.ccm/${cluster}/node1/conf/server-keystore.jks
cp node2-server-keystore.jks ~/.ccm/${cluster}/node2/conf/server-keystore.jks
cp node3-server-keystore.jks ~/.ccm/${cluster}/node3/conf/server-keystore.jks
cp generic-server-truststore.jks
~/.ccm/${cluster}/node1/conf/server-truststore.jks
cp generic-server-tru
[jira] [Commented] (CASSANDRA-16003) ToolRunner added in CASSANDRA-15942 isn't portable
[
https://issues.apache.org/jira/browse/CASSANDRA-16003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168261#comment-17168261
]
David Capwell commented on CASSANDRA-16003:
---
It would also be good to fix the asserts as they are not actionable; they
should inform what happened to cause the issue (such as print out stderr if it
is expected to be empty but was not)
> ToolRunner added in CASSANDRA-15942 isn't portable
> --
>
> Key: CASSANDRA-16003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16003
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The JVM will output to stderr on some environments to show what flags that
> were picked up, when this happens all tests which validate stderr start to
> fail. This was found in the org.apache.cassandra.tools.ClearSnapshotTest as
> it switched to use the ToolRunner; below is a sample failure on my laptop (I
> had to modify the asserts since they don’t include the input)
> {code}
> java.lang.AssertionError:
> Expecting empty but was:<"Picked up _JAVA_OPTIONS:
> -Djava.net.preferIPv4Stack=true
> ">
> at
> org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:339)
> at
> org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:334)
> at
> org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
> {code}
> Here _JAVA_OPTIONS is used globally on my system so fails the test; there is
> also JAVA_TOOL_RUNNER which is used the same way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168259#comment-17168259 ] David Capwell commented on CASSANDRA-15583: --- Added CASSANDRA-16003. The tests that depend on ToolRunner fail for me and fail in some CI environments because of the stderr check. > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest, Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). > ||Tool||UX test||UT coverage||dtest coverage||Comments|| > |Nodetool|(x)|(x)|(!)|Deserves it's own ticket. Not all the sub commands are > tested. Dtest also test nodetool as a side effect| > |Cqlsh|(x)|(x)|(!)|Deserves it's own ticket| > |Cassandra-stress|(x)|(x)|(x)|Some UT. Deserves it's own ticket| > |debug-cql|(x)|(x)|(x)|Deserves it's own ticket | > |fqltool|(x)|(/)|(!)|Deserves it's own ticket | > |auditlogviewer|(/)|(!)|(!)|UX tests: C-15991. Docs missing option -i| > |*Sstable utilities*| | | | | > |sstabledump|(/)|(x)|(!)|UX tests: C-15991| > |sstableexpiredblockers|(/)|(x)|(!)|UX tests: C-15991| > |sstablelevelreset|(/)|(x)|(!)|UX tests: C-15991| > |sstableloader|(x)|(x)|(!)|Needs it's own ticket probably| > |sstablemetadata|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, missing options in docs, brittle args parsing| > |sstableofflinerelevel|(/)|(x)|(!)|UX tests: C-15991, brittle args parsing| > |sstablerepairedset|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, brittle args parsing| > |sstablescrub|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs| > |sstablesplit|(/)|(x)|(!)|UX tests: C-15991| > |sstableupgrade|(/)|(x)|(!)|UX tests: C-15991| > |sstableutil|(/)|(x)|(!)|UX tests: C-15991| > |sstableverify|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs + > broken token_range option| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16003) ToolRunner added in CASSANDRA-15942 isn't portable
[
https://issues.apache.org/jira/browse/CASSANDRA-16003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16003:
--
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Low Hanging Fruit
Discovered By: Unit Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> ToolRunner added in CASSANDRA-15942 isn't portable
> --
>
> Key: CASSANDRA-16003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16003
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The JVM will output to stderr on some environments to show what flags that
> were picked up, when this happens all tests which validate stderr start to
> fail. This was found in the org.apache.cassandra.tools.ClearSnapshotTest as
> it switched to use the ToolRunner; below is a sample failure on my laptop (I
> had to modify the asserts since they don’t include the input)
> {code}
> java.lang.AssertionError:
> Expecting empty but was:<"Picked up _JAVA_OPTIONS:
> -Djava.net.preferIPv4Stack=true
> ">
> at
> org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:339)
> at
> org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:334)
> at
> org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
> {code}
> Here _JAVA_OPTIONS is used globally on my system so fails the test; there is
> also JAVA_TOOL_RUNNER which is used the same way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16003) ToolRunner added in CASSANDRA-15942 isn't portable
David Capwell created CASSANDRA-16003:
-
Summary: ToolRunner added in CASSANDRA-15942 isn't portable
Key: CASSANDRA-16003
URL: https://issues.apache.org/jira/browse/CASSANDRA-16003
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: David Capwell
The JVM will output to stderr on some environments to show what flags that were
picked up, when this happens all tests which validate stderr start to fail.
This was found in the org.apache.cassandra.tools.ClearSnapshotTest as it
switched to use the ToolRunner; below is a sample failure on my laptop (I had
to modify the asserts since they don’t include the input)
{code}
java.lang.AssertionError:
Expecting empty but was:<"Picked up _JAVA_OPTIONS:
-Djava.net.preferIPv4Stack=true
">
at
org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:339)
at
org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:334)
at
org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
{code}
Here _JAVA_OPTIONS is used globally on my system so fails the test; there is
also JAVA_TOOL_RUNNER which is used the same way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168240#comment-17168240
]
Blake Eggleston commented on CASSANDRA-15861:
-
This is pretty close, I just have a few things to address.
1) Orphaned hard links need to be cleaned up on startup.
2) Using the streaming session id for the hard link name, instead of a time
uuid, would make debugging some issues easier.
3) ComponentManifest: the changes to this class feel a bit awkward to me. I
think it would be cleaner if hard link creation and management was handled by a
separate class. It should also be autocloseable so we're not deleting hard
links in a finally block.
4) Concurrency: This is much better wrt concurrency, but I think there's still
some room for improvement. The main thing I'm concerned about is the nested
lock acquisition in {{cloneWithNewSummarySamplingLevel}}. This makes it easier
to introduce deadlocks in the future, and we should avoid doing this if we can.
In this case, if you could guarantee that no more than 1 index resample can
happen at once for a given sstable, the only thing you'd need to synchronize in
`cloneWithNewSummarySamplingLevel` is `saveSummary`. If you did that, you could
just synchronize hard link creation on `tidy.global`, instead of introducing a
new lock.
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to br
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168236#comment-17168236
]
David Capwell commented on CASSANDRA-15907:
---
Found the root cause for ClearSnapshotTest
{code}
java.lang.AssertionError:
Expecting empty but was:<"Picked up _JAVA_OPTIONS:
-Djava.net.preferIPv4Stack=true
">
{code}
Looks like the test was rewritten recently and asserts stderr is empty. The
issue is that the JVM can print to stdout in some cases, so this check isn't
portable.
Here, I have used "_JAVA_OPTIONS" to globally make sure ipv4 is setup, in CI we
make sure the error files get dumped to a location which can be saved; so
failed for my CI and locally for this reason; since this is not related to this
ticket, will file a different one.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassa
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168233#comment-17168233
]
Andres de la Peña commented on CASSANDRA-15907:
---
[~dcapwell] good catch, I missed a change in {{DatabaseDescriptorRefTest}}
during the merge. I have just fixed it. I can't reproduce the failure in
{{ClearSnapshotTest}}, though.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (292650d -> 7e6f491)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 292650d Merge branch 'cassandra-3.11' into trunk new e318841 ninja fix failure in DatabaseDescriptorRefTest new 7e6f491 Merge branch 'cassandra-3.11' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java | 1 + 1 file changed, 1 insertion(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7e6f491ca18c86776372b793e2472fe8a92736d6 Merge: 292650d e318841 Author: Andrés de la Peña AuthorDate: Thu Jul 30 22:21:02 2020 +0100 Merge branch 'cassandra-3.11' into trunk # Conflicts: # test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java | 1 + 1 file changed, 1 insertion(+) diff --cc test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java index 8f731e2,88c965b..181adbf --- a/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java +++ b/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java @@@ -85,7 -77,7 +85,8 @@@ public class DatabaseDescriptorRefTes "org.apache.cassandra.config.EncryptionOptions$ClientEncryptionOptions", "org.apache.cassandra.config.EncryptionOptions$ServerEncryptionOptions", "org.apache.cassandra.config.EncryptionOptions$ServerEncryptionOptions$InternodeEncryption", + "org.apache.cassandra.config.EncryptionOptions$ServerEncryptionOptions$OutgoingEncryptedPortSource", + "org.apache.cassandra.config.ReplicaFilteringProtectionOptions", "org.apache.cassandra.config.YamlConfigurationLoader", "org.apache.cassandra.config.YamlConfigurationLoader$PropertiesChecker", "org.apache.cassandra.config.YamlConfigurationLoader$PropertiesChecker$1", - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: ninja fix failure in DatabaseDescriptorRefTest
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.11 by this push: new e318841 ninja fix failure in DatabaseDescriptorRefTest e318841 is described below commit e3188417568e94b3a2fd8ddf834d0eb77245522f Author: Andrés de la Peña AuthorDate: Thu Jul 30 22:16:42 2020 +0100 ninja fix failure in DatabaseDescriptorRefTest Caused by merge error in CASSANDRA-15907 --- test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java | 1 + 1 file changed, 1 insertion(+) diff --git a/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java b/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java index ce59c01..88c965b 100644 --- a/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java +++ b/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java @@ -77,6 +77,7 @@ public class DatabaseDescriptorRefTest "org.apache.cassandra.config.EncryptionOptions$ClientEncryptionOptions", "org.apache.cassandra.config.EncryptionOptions$ServerEncryptionOptions", "org.apache.cassandra.config.EncryptionOptions$ServerEncryptionOptions$InternodeEncryption", +"org.apache.cassandra.config.ReplicaFilteringProtectionOptions", "org.apache.cassandra.config.YamlConfigurationLoader", "org.apache.cassandra.config.YamlConfigurationLoader$PropertiesChecker", "org.apache.cassandra.config.YamlConfigurationLoader$PropertiesChecker$1", - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168220#comment-17168220
]
David Capwell commented on CASSANDRA-16002:
---
Ran all upgrade tests on java 11 and they passed. There were unit test
failures but they are the same ones active on trunk right now.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM or using standard disk access mode");
> }
> canCleanDirectBuffers = canClean;
> }
> {code}
>
[jira] [Issue Comment Deleted] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15907:
Comment: was deleted
(was: [~adelapena] Something might be going on with \{{ant test
-Dtest.name=DatabaseDescriptorRefTest}} (on \{{trunk}}). Do you see it failing
locally?
CC [~dcapwell])
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168206#comment-17168206
]
Caleb Rackliffe commented on CASSANDRA-15907:
-
[~adelapena] Something might be going on with \{{ant test
-Dtest.name=DatabaseDescriptorRefTest}} (on \{{trunk}}). Do you see it failing
locally?
CC [~dcapwell]
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168203#comment-17168203
]
Ekaterina Dimitrova edited comment on CASSANDRA-13994 at 7/30/20, 8:37 PM:
---
[~jwest] , I heard that you are familiar with the compact storage codebase,
will you be able to do a quick review for me this week ? I really want to get
this ticket move forward if you have some time.
was (Author: e.dimitrova):
[~jwest] , I heard that you are familiar with the compact storage codebase,
will you be able to do a quick review for me this week ? I really like to get
this ticket move forward if you have some time.
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168203#comment-17168203
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
[~jwest] , I heard that you are familiar with the compaction storage codebase,
will you be able to do a quick review for me this week ? I really like to get
this ticket move forward if you have some time.
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168203#comment-17168203
]
Ekaterina Dimitrova edited comment on CASSANDRA-13994 at 7/30/20, 8:36 PM:
---
[~jwest] , I heard that you are familiar with the compact storage codebase,
will you be able to do a quick review for me this week ? I really like to get
this ticket move forward if you have some time.
was (Author: e.dimitrova):
[~jwest] , I heard that you are familiar with the compaction storage codebase,
will you be able to do a quick review for me this week ? I really like to get
this ticket move forward if you have some time.
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168200#comment-17168200
]
David Capwell edited comment on CASSANDRA-15907 at 7/30/20, 8:35 PM:
-
FYI org.apache.cassandra.config.DatabaseDescriptorRefTest is failing
https://app.circleci.com/pipelines/github/dcapwell/cassandra/379/workflows/83c3e1f6-3279-4426-8af8-a02926b10774/jobs/1975
{code}
git checkout trunk
git pull --rebase upstream trunk
ant realclean && ant && ant generate-idea-files
ant testclasslist -Dtest.classlistfile=<(echo
org/apache/cassandra/config/DatabaseDescriptorRefTest.java)
-Dtest.classlistprefix=unit
...
[junit-timeout] Testcase:
testDatabaseDescriptorRef(org.apache.cassandra.config.DatabaseDescriptorRefTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptorRefTest.checkViolations(DatabaseDescriptorRefTest.java:303)
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:287)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.config.DatabaseDescriptorRefTest
FAILED
[junitreport] Processing
/Users/davidcapwell/src/github/apache/cassandra-trunk/build/test/TESTS-TestSuites.xml
to /var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null2013776906
[junitreport] Loading stylesheet
jar:file:/usr/local/Cellar/ant/1.10.7/libexec/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 277ms
[junitreport] Deleting:
/var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null2013776906
BUILD FAILED
/Users/davidcapwell/src/github/apache/cassandra-trunk/build.xml:1981: The
following error occurred while executing this line:
/Users/davidcapwell/src/github/apache/cassandra-trunk/build.xml:1871: Some
test(s) failed.
{code}
looks like clear snapshot as well, not sure why it passed in circle ci
{code}
ant testclasslist -Dtest.classlistfile=<(echo
org/apache/cassandra/tools/ClearSnapshotTest.java) -Dtest.classlistprefix=unit
...
[junit-timeout] Testsuite: org.apache.cassandra.tools.ClearSnapshotTest Tests
run: 4, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 8.175 sec
[junit-timeout]
[junit-timeout] Testcase:
testClearSnapshot_RemoveMultiple(org.apache.cassandra.tools.ClearSnapshotTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:338)
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:333)
[junit-timeout] at
org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
[junit-timeout]
[junit-timeout]
[junit-timeout] Testcase:
testClearSnapshot_NoArgs(org.apache.cassandra.tools.ClearSnapshotTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:338)
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:333)
[junit-timeout] at
org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_NoArgs(ClearSnapshotTest.java:61)
[junit-timeout]
[junit-timeout]
[junit-timeout] Testcase:
testClearSnapshot_RemoveByName(org.apache.cassandra.tools.ClearSnapshotTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:338)
[junit-timeout] at
org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:333)
[junit-timeout] at
org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveByName(ClearSnapshotTest.java:75)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.tools.ClearSnapshotTest FAILED
{code}
was (Author: dcapwell):
FYI org.apache.cassandra.config.DatabaseDescriptorRefTest is failing
https://app.circleci.com/pipelines/github/dcapwell/cassandra/379/workflows/83c3e1f6-3279-4426-8af8-a02926b10774/jobs/1975
{code}
git checkout trunk
git pull --rebase upstream trunk
ant realclean && ant && ant generate-idea-files
ant testclasslist -Dtest.classlistfile=<(echo
org/apache/cassandra/config/DatabaseDescriptorRefTest.java)
-Dtest.classlistprefix=unit
...
[junit-timeout] Testcase:
testDatabaseDescriptorRef(org.apache.cassandra.config.DatabaseDescriptorRefTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptorRefTest.checkViolations(DatabaseDescriptorRefTes
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168200#comment-17168200
]
David Capwell commented on CASSANDRA-15907:
---
FYI org.apache.cassandra.config.DatabaseDescriptorRefTest is failing
https://app.circleci.com/pipelines/github/dcapwell/cassandra/379/workflows/83c3e1f6-3279-4426-8af8-a02926b10774/jobs/1975
{code}
git checkout trunk
git pull --rebase upstream trunk
ant realclean && ant && ant generate-idea-files
ant testclasslist -Dtest.classlistfile=<(echo
org/apache/cassandra/config/DatabaseDescriptorRefTest.java)
-Dtest.classlistprefix=unit
...
[junit-timeout] Testcase:
testDatabaseDescriptorRef(org.apache.cassandra.config.DatabaseDescriptorRefTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptorRefTest.checkViolations(DatabaseDescriptorRefTest.java:303)
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:287)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.config.DatabaseDescriptorRefTest
FAILED
[junitreport] Processing
/Users/davidcapwell/src/github/apache/cassandra-trunk/build/test/TESTS-TestSuites.xml
to /var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null2013776906
[junitreport] Loading stylesheet
jar:file:/usr/local/Cellar/ant/1.10.7/libexec/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 277ms
[junitreport] Deleting:
/var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null2013776906
BUILD FAILED
/Users/davidcapwell/src/github/apache/cassandra-trunk/build.xml:1981: The
following error occurred while executing this line:
/Users/davidcapwell/src/github/apache/cassandra-trunk/build.xml:1871: Some
test(s) failed.
{code}
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row re
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168182#comment-17168182
]
Jordan West edited comment on CASSANDRA-16002 at 7/30/20, 7:51 PM:
---
+1 LGTM. For 3.0/3.11 moving the logging line above the stability inspector
call makes sense because the JVM can be killed before reaching the log line.
For trunk, logging the exceptions for additional information also makes sense.
So does registering the error handler after initializing {{DatabaseDescriptor}}
in all cases.
was (Author: jrwest):
+1 LGTM. For 3.0/3.11 moving the logging line above the stability inspector
call makes sense because the JVM can be killed before reaching the log line.
For trunk, logging the exceptions for additional information also makes sense.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
>
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-16002:
Reviewers: Jordan West, Jordan West (was: Jordan West)
Jordan West, Jordan West
Status: Review In Progress (was: Patch Available)
+1 LGTM. For 3.0/3.11 moving the logging line above the stability inspector
call makes sense because the JVM can be killed before reaching the log line.
For trunk, logging the exceptions for additional information also makes sense.
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Ora
[jira] [Comment Edited] (CASSANDRA-15988) Add nodetool getfullquerylog
[
https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168177#comment-17168177
]
Ekaterina Dimitrova edited comment on CASSANDRA-15988 at 7/30/20, 7:45 PM:
---
Whoever does this, probably it would be a good idea to add a good warning in
case someone didn't configure the yaml and tried to enable the tool without
adding the path parameter so it is clear what minimum config was missed.
Now we get below and it is kind of confusing I think:
{code:java}
[ec2-user@ip-172-31-16-87 ~]$ nodetool enablefullquerylog
nodetool: path exists and is not a directory or couldn't be created
{code}
It should say at least "or you might have missed to specify a
directory"...something like that
was (Author: e.dimitrova):
Whoever does this, probably it would be a good idea to add a good warning in
case someone didn't configure the yaml and tried to enable the tool without
adding the path parameter so it is clear what minimum config was missed.
Now we get below and it is kind of confusing I think:
{code:java}
[ec2-user@ip-172-31-16-87 ~]$ nodetool enablefullquerylog
nodetool: path exists and is not a directory or couldn't be created
{code}
> Add nodetool getfullquerylog
> -
>
> Key: CASSANDRA-15988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15988
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/fql
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> This ticket is raised based on CASSANDRA-15791 and valuable feedback provided
> by [~jshook].
> There are two outstanding questions:
> * forming the exact shape of such a command and how it can benefit the
> users; to be discussed in detail in this ticket
> * Is this a thing we as a project can add to 4.0 beta or it should be
> considered in 4.1 for example
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15988) Add nodetool getfullquerylog
[
https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168177#comment-17168177
]
Ekaterina Dimitrova commented on CASSANDRA-15988:
-
Whoever does this, probably it would be a good idea to add a good warning in
case someone didn't configure the yaml and tried to enable the tool without
adding the path parameter so it is clear what minimum config was missed.
Now we get below and it is kind of confusing I think:
{code:java}
[ec2-user@ip-172-31-16-87 ~]$ nodetool enablefullquerylog
nodetool: path exists and is not a directory or couldn't be created
{code}
> Add nodetool getfullquerylog
> -
>
> Key: CASSANDRA-15988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15988
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/fql
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> This ticket is raised based on CASSANDRA-15791 and valuable feedback provided
> by [~jshook].
> There are two outstanding questions:
> * forming the exact shape of such a command and how it can benefit the
> users; to be discussed in detail in this ticket
> * Is this a thing we as a project can add to 4.0 beta or it should be
> considered in 4.1 for example
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15981) jvm-dtests crash on java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168171#comment-17168171
]
David Capwell commented on CASSANDRA-15981:
---
in testing found CASSANDRA-16002. I wanted to make sure upgrade tests were
stable with my changes, but found upgrade kept failing; once fixed ill retest
(normal tests were stable).
> jvm-dtests crash on java 11
> ---
>
> Key: CASSANDRA-15981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15981
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> There is a race condition bug with CMS and class unloading which cause the
> JVM to crash. Since jvm-dtests rely on class loaders and unloading, this
> causes sporadic JVM crashes that look like the following in CI logs
> {code}
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168150#comment-17168150
]
David Capwell commented on CASSANDRA-16002:
---
With the patch I get the following
{code}
testclasslist:
[testparallelhelper] Warning: Nashorn engine is planned to be removed from a
future JDK release
[echo] Number of test runners: 1
[mkdir] Created dir:
/Users/davidcapwell/src/github/apache/cassandra-trunk/build/test/cassandra
[mkdir] Created dir:
/Users/davidcapwell/src/github/apache/cassandra-trunk/build/test/output
[junit-timeout] Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
[junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was
deprecated in version 9.0 and will likely be removed in a future release.
[junit-timeout] Testsuite: org.apache.cassandra.distributed.upgrade.UpgradeTest
[junit-timeout] Testsuite: org.apache.cassandra.distributed.upgrade.UpgradeTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 49.363 sec
[junit-timeout]
[junitreport] Processing
/Users/davidcapwell/src/github/apache/cassandra-trunk/build/test/TESTS-TestSuites.xml
to /var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null1381087585
[junitreport] Loading stylesheet
jar:file:/usr/local/Cellar/ant/1.10.7/libexec/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 368ms
[junitreport] Deleting:
/var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null1381087585
BUILD SUCCESSFUL
Total time: 54 seconds
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpoint
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16002:
--
Test and Documentation Plan: manual testing
Status: Patch Available (was: Open)
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM or using standard disk access mode");
> }
> canCleanDirectBuffers = canClean;
> }
> {code}
> JVMStabilityInspector will check the throwable which will eventually call
> org.apa
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168142#comment-17168142
]
David Capwell edited comment on CASSANDRA-16002 at 7/30/20, 6:55 PM:
-
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
As of java 11, the cleaner is now jdk.internal.ref.Cleaner
was (Author: dcapwell):
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
As of java 11, the cleaner is now jdk.internal.ref.Cleaner
So, in order to get the upgrade tests working again, we will need to backport
CASSANDRA-9608 as well
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168142#comment-17168142
]
David Capwell edited comment on CASSANDRA-16002 at 7/30/20, 6:50 PM:
-
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
As of java 11, the cleaner is now jdk.internal.ref.Cleaner
So, in order to get the upgrade tests working again, we will need to backport
CASSANDRA-9608 as well
was (Author: dcapwell):
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
As of java 11, the cleaner is now jdk.internal.ref.Cleaner
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168142#comment-17168142
]
David Capwell edited comment on CASSANDRA-16002 at 7/30/20, 6:47 PM:
-
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
As of java 11, the cleaner is now jdk.internal.ref.Cleaner
was (Author: dcapwell):
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
>
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168142#comment-17168142
]
David Capwell commented on CASSANDRA-16002:
---
The underline exception is
{code}
ERROR [node1_isolatedExecutor:1] node1 2020-07-30 11:44:38,115 Cannot
initialize un-mmaper. (Are you using a non-Oracle JVM?) Compacted data files
will not be removed promptly. Consider using an Oracle JVM or using standard
disk access mode
java.lang.NoSuchMethodError: sun.nio.ch.DirectBuffer.cleaner()Lsun/misc/Cleaner;
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:73)
~[dtest-3.0.22.jar:na]
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
~[dtest-3.0.22.jar:na]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
~[dtest-3.0.22.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> o
[jira] [Comment Edited] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168141#comment-17168141
]
David Capwell edited comment on CASSANDRA-16002 at 7/30/20, 6:45 PM:
-
OSS CI doesn't do upgrade tests with java 11, so need to replicate by hand
{code}
ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
...
[junit-timeout] Testcase:
upgradeTest(org.apache.cassandra.distributed.upgrade.UpgradeTest):Caused an
ERROR
[junit-timeout] java.lang.RuntimeException: java.lang.AssertionError: network
topology must be assigned before using snitch
[junit-timeout] java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.AssertionError: network topology must be assigned before using snitch
[junit-timeout] at
org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
[junit-timeout] at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
[junit-timeout] at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
[junit-timeout] at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
[junit-timeout] at
org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] Caused by: java.lang.RuntimeException:
java.lang.AssertionError: network topology must be assigned before using snitch
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
[junit-timeout] at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[junit-timeout] at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[junit-timeout] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[junit-timeout] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[junit-timeout] at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
[junit-timeout] at java.base/java.lang.Thread.run(Thread.java:834)
[junit-timeout] Caused by: java.lang.AssertionError: network topology must be
assigned before using snitch
[junit-timeout] at
org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
[junit-timeout] at
org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
[junit-timeout] at
org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
[junit-timeout] at
org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
[junit-timeout] at
org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
[junit-timeout] at
org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
[junit-timeout] at
org.apache.cassandra.io.util.FileUtils.(FileUtils.java:79)
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.distributed.upgrade.UpgradeTest FAILED
...
{code}
was (Author: dcapwell):
OSS CI doesn't do upgrade tests with java 11, so need to replicate by hand
{code}
ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
>
[jira] [Commented] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168141#comment-17168141
]
David Capwell commented on CASSANDRA-16002:
---
OSS CI doesn't do upgrade tests with java 11, so need to replicate by hand
{code}
ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/upgrade/UpgradeTest.java" )
-Dtest.classlistprefix=distributed
{code}
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an Oracle JVM o
[jira] [Updated] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
[
https://issues.apache.org/jira/browse/CASSANDRA-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16002:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Low Hanging Fruit
Discovered By: Unit Test
Fix Version/s: 4.0-beta
3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> jvm upgrade dtests fail on java 11 caused by bad initialization order of
> DatabaseDescriptor and FileUtils
> -
>
> Key: CASSANDRA-16002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> In FileUtils we check to see if we have access to some classes (specifically
> to set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can
> fail in java 11. This is fine with CassandraDaemon as it will just log the
> failure, but in in-jvm dtests this can fail to startup an instance with the
> following
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: network topology must be assigned before using
> snitch
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
> topology must be assigned before using snitch
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.AssertionError: network topology must be assigned before
> using snitch
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
> at
> org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
> at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
> {code}
> The exception isn’t clear, but what is happening is the following
> {code}
> static
> {
> boolean canClean = false;
> try
> {
> ByteBuffer buf = ByteBuffer.allocateDirect(1);
> ((DirectBuffer) buf).cleaner().clean();
> canClean = true;
> }
> catch (Throwable t)
> {
> JVMStabilityInspector.inspectThrowable(t);
> logger.info("Cannot initialize un-mmaper. (Are you using a
> non-Oracle JVM?) Compacted data files will not be removed promptly.
> Consider using an
[jira] [Created] (CASSANDRA-16002) jvm upgrade dtests fail on java 11 caused by bad initialization order of DatabaseDescriptor and FileUtils
David Capwell created CASSANDRA-16002:
-
Summary: jvm upgrade dtests fail on java 11 caused by bad
initialization order of DatabaseDescriptor and FileUtils
Key: CASSANDRA-16002
URL: https://issues.apache.org/jira/browse/CASSANDRA-16002
Project: Cassandra
Issue Type: Bug
Components: Test/dtest
Reporter: David Capwell
Assignee: David Capwell
In FileUtils we check to see if we have access to some classes (specifically to
set org.apache.cassandra.io.util.FileUtils#isCleanerAvailable), which can fail
in java 11. This is fine with CassandraDaemon as it will just log the failure,
but in in-jvm dtests this can fail to startup an instance with the following
{code}
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.AssertionError: network topology must be assigned before using snitch
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
at
org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:592)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:209)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:200)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:179)
at
org.apache.cassandra.distributed.upgrade.UpgradeTest.upgradeTest(UpgradeTest.java:50)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.lang.RuntimeException: java.lang.AssertionError: network
topology must be assigned before using snitch
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:590)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.AssertionError: network topology must be assigned before
using snitch
at
org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:90)
at
org.apache.cassandra.distributed.impl.DistributedTestSnitch.getDatacenter(DistributedTestSnitch.java:85)
at
org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:118)
at
org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:488)
at
org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:137)
at
org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:102)
at
org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:60)
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:78)
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$7(Instance.java:509)
{code}
The exception isn’t clear, but what is happening is the following
{code}
static
{
boolean canClean = false;
try
{
ByteBuffer buf = ByteBuffer.allocateDirect(1);
((DirectBuffer) buf).cleaner().clean();
canClean = true;
}
catch (Throwable t)
{
JVMStabilityInspector.inspectThrowable(t);
logger.info("Cannot initialize un-mmaper. (Are you using a non-Oracle
JVM?) Compacted data files will not be removed promptly. Consider using an
Oracle JVM or using standard disk access mode");
}
canCleanDirectBuffers = canClean;
}
{code}
JVMStabilityInspector will check the throwable which will eventually call
org.apache.cassandra.config.DatabaseDescriptor#getDiskFailurePolicy which will
try to load the configs and fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Since Version: 3.0.21
Source Control Link: n/a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Reviewers: Brice Figureau, Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Status: Ready to Commit (was: Review In Progress)
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168105#comment-17168105
]
Brice Figureau commented on CASSANDRA-15999:
I confirm this is now working.
Many thanks for fixing the problem so quickly!
You can close the ticket.
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15981) jvm-dtests crash on java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168095#comment-17168095
]
David Capwell commented on CASSANDRA-15981:
---
testing out a change that defines max meatspace only in java 8 and
-CMSClassUnloadingEnabled on java 11. I am testing by running jvm-dtests and
upgrade jvm-dtests with 4gb containers repeatedly; this method helps show there
is a problem, so should show that it is resolved.
> jvm-dtests crash on java 11
> ---
>
> Key: CASSANDRA-15981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15981
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> There is a race condition bug with CMS and class unloading which cause the
> JVM to crash. Since jvm-dtests rely on class loaders and unloading, this
> causes sporadic JVM crashes that look like the following in CI logs
> {code}
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15981) jvm-dtests crash on java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-15981:
-
Assignee: David Capwell
> jvm-dtests crash on java 11
> ---
>
> Key: CASSANDRA-15981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15981
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> There is a race condition bug with CMS and class unloading which cause the
> JVM to crash. Since jvm-dtests rely on class loaders and unloading, this
> causes sporadic JVM crashes that look like the following in CI logs
> {code}
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168034#comment-17168034
]
Michael Semb Wever commented on CASSANDRA-15999:
Tested fresh 3.0.21 install on a docker ubuntu:latest image. Works now.
[~masterzen], could you please confirm that it works for you? so I can close
this ticket…
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Fix Version/s: (was: 3.0.x)
3.0.21
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.21
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Test and Documentation Plan: apt-get install cassandra
Status: Patch Available (was: In Progress)
All {{3.0.21}} files in
https://apache.bintray.com/cassandra/pool/main/c/cassandra/ have been uploaded
again, from https://dist.apache.org/repos/dist/release/cassandra/3.0.21/debian/
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.x
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15586) 4.0 quality testing: Cluster Setup and Maintenance
[ https://issues.apache.org/jira/browse/CASSANDRA-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168023#comment-17168023 ] Ekaterina Dimitrova commented on CASSANDRA-15586: - CASSANDRA-16000, CASSANDRA-16001 logged > 4.0 quality testing: Cluster Setup and Maintenance > -- > > Key: CASSANDRA-15586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15586 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-beta > > > We want 4.0 to be easy for users to setup out of the box and just work. This > means having low friction when users download the Cassandra package and start > running it. For example, users should be able to easily configure and start > new 4.0 clusters and have tokens distributed evenly. Another example is > packaging, it should be easy to install Cassandra on all supported platforms > (e.g. packaging) and have Cassandra use standard platform integrations. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16001) Log name change required
[ https://issues.apache.org/jira/browse/CASSANDRA-16001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16001: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Packaging Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Log name change required > > > Key: CASSANDRA-16001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16001 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Ekaterina Dimitrova >Priority: Normal > > Under Installing the RPM Packages, the currently created log Is > cassandra.log, not system.log -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16001) Log name change required
Ekaterina Dimitrova created CASSANDRA-16001: --- Summary: Log name change required Key: CASSANDRA-16001 URL: https://issues.apache.org/jira/browse/CASSANDRA-16001 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Under Installing the RPM Packages, the currently created log Is cassandra.log, not system.log -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16000) Updates needed after 4.0-beta1 release
[ https://issues.apache.org/jira/browse/CASSANDRA-16000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16000: Description: We need to update for beta the Documentation/Installing Cassandra (also the curl link provided) (was: * We need to update for beta the Documentation/Installing Cassandra (also the curl link provided) * Under Installing the RPM Packages, the currently created log Is cassandra.log, not system.log) > Updates needed after 4.0-beta1 release > -- > > Key: CASSANDRA-16000 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16000 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-beta > > > We need to update for beta the Documentation/Installing Cassandra (also the > curl link provided) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16000) Updates needed after 4.0-beta1 release
[ https://issues.apache.org/jira/browse/CASSANDRA-16000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16000: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Documentation/Website Discovered By: User Report Fix Version/s: 4.0-beta 4.0 Severity: Normal Status: Open (was: Triage Needed) > Updates needed after 4.0-beta1 release > -- > > Key: CASSANDRA-16000 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16000 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-beta > > > * We need to update for beta the Documentation/Installing Cassandra (also the > curl link provided) > * Under Installing the RPM Packages, the currently created log Is > cassandra.log, not system.log -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16000) Updates needed after 4.0-beta1 release
Ekaterina Dimitrova created CASSANDRA-16000: --- Summary: Updates needed after 4.0-beta1 release Key: CASSANDRA-16000 URL: https://issues.apache.org/jira/browse/CASSANDRA-16000 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova * We need to update for beta the Documentation/Installing Cassandra (also the curl link provided) * Under Installing the RPM Packages, the currently created log Is cassandra.log, not system.log -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168006#comment-17168006
]
Michael Semb Wever commented on CASSANDRA-15999:
Definitely files missing in bintray.
Screenshot from
https://bintray.com/apache/cassandra/debian#files/pool%2Fmain%2Fc%2Fcassandra
!Screen Shot 2020-07-30 at 17.30.41.png|width=400px!
The files were uploaded during the release process while bintray was suffering
an outage. I wasn't aware of the outage until afterwards when I went to publish
them and couldn't. Later on when things were working I poorly presumed the
publish included all files.
Adding the missing files now. Thanks for the report [~masterzen].
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.x
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Attachment: Screen Shot 2020-07-30 at 17.30.41.png
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.x
>
> Attachments: Screen Shot 2020-07-30 at 17.30.41.png
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15999:
---
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 3.0.x
Severity: Normal
Assignee: Michael Semb Wever
Status: Open (was: Triage Needed)
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.0.x
>
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15965) Fix flaky test StreamingInboundHandlerTest channelRead_Normal
[
https://issues.apache.org/jira/browse/CASSANDRA-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168000#comment-17168000
]
Brandon Williams commented on CASSANDRA-15965:
--
I was able to reproduce this in only 59 runs the first time, but after adding
some debug logging in AsyncStreamingInputPlus.unsafeAvailable, I'm unable to
repro in thousands of runs. There is clearly some kind of timing issue here,
but I'm not familiar enough with Netty to know exactly where.
> Fix flaky test StreamingInboundHandlerTest channelRead_Normal
> -
>
> Key: CASSANDRA-15965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15965
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> channelRead_Normal -
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest
> {code}
> junit.framework.AssertionFailedError: expected:<8> but was:<0>
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandlerTest.channelRead_Normal(StreamingInboundHandlerTest.java:98)
> {code}
> Failed build:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/298/workflows/e3296f33-2289-401c-8fc8-a7f786e3692a/jobs/1445
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
[
https://issues.apache.org/jira/browse/CASSANDRA-15999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167997#comment-17167997
]
Brandon Williams commented on CASSANDRA-15999:
--
I suspect this is caused by the bintray outage [~mck] noted in the release
email, but I'm not sure if it just fixes itself.
> Cassandra 3.0.21 debian package is half available
> -
>
> Key: CASSANDRA-15999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brice Figureau
>Priority: Normal
>
> Hi,
> Cassandra 3.0.21 seems to have been released in the debian package
> repository, as it is selected by an {{apt install cassandra}} however the
> {{.deb}} is not available in the repository (only the {{.dsc}}):
>
> {code:java}
> # apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
> cassandra-tools
> The following packages will be upgraded:
> cassandra cassandra-tools
> 2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
> Need to get 25.5 MB/25.5 MB of archives.
> After this operation, 37.9 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
> 3.0.21
> Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra
> all 3.0.21
> 404 Not Found [IP: 52.58.94.94 443]
> E: Failed to fetch
> http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
> 404 Not Found [IP: 52.58.94.94 443]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
> {code}
>
> Indeed, there's no
> {{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
> file avaible.
> {{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20
> is available though.
> My current workaround is to use apt-pinning to pin to 3.0.20 until the
> problem is resolved.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15907:
--
Fix Version/s: (was: 4.0-beta)
(was: 3.11.x)
(was: 3.0.x)
4.0-beta2
3.11.8
3.0.22
Source Control Link:
https://github.com/apache/cassandra/commit/e5c3d08a1428d378b6690f0419a2b25724b9736e
(was: https://github.com/apache/cassandra/pull/659 (3.0))
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.22, 3.11.8, 4.0-beta2
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167908#comment-17167908
]
Andres de la Peña commented on CASSANDRA-15907:
---
Committed to 3.0 as
[e5c3d08a1428d378b6690f0419a2b25724b9736e|https://github.com/apache/cassandra/commit/e5c3d08a1428d378b6690f0419a2b25724b9736e]
and merged up to
[3.11|https://github.com/apache/cassandra/commit/2ef1f1c150e3d3f297e86c2b2efedd964a43b3c9]
and
[trunk|https://github.com/apache/cassandra/commit/292650d968c30757a027905d12c7370c6342dbe3].
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 292650d968c30757a027905d12c7370c6342dbe3 Merge: 3e393f2 2ef1f1c Author: Caleb Rackliffe AuthorDate: Thu Jul 30 14:10:48 2020 +0100 Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 1 + build.xml | 3 +- conf/cassandra.yaml| 20 + doc/source/operating/metrics.rst | 144 +++ src/java/org/apache/cassandra/config/Config.java | 2 + .../cassandra/config/DatabaseDescriptor.java | 20 + .../config/ReplicaFilteringProtectionOptions.java | 28 ++ .../db/partitions/PartitionIterators.java | 47 +++ .../org/apache/cassandra/metrics/TableMetrics.java | 21 +- .../apache/cassandra/service/StorageService.java | 28 +- .../cassandra/service/StorageServiceMBean.java | 12 + .../cassandra/service/reads/DataResolver.java | 57 ++- .../service/reads/ReplicaFilteringProtection.java | 444 - .../reads/ShortReadPartitionsProtection.java | 10 +- .../service/reads/ShortReadProtection.java | 17 +- .../service/reads/repair/NoopReadRepair.java | 3 +- .../org/apache/cassandra/transport/Message.java| 2 +- .../cassandra/utils/concurrent/Accumulator.java| 9 +- .../cassandra/distributed/impl/Coordinator.java| 10 + .../apache/cassandra/distributed/impl/RowUtil.java | 7 +- .../test/ReplicaFilteringProtectionTest.java | 244 +++ .../utils/concurrent/AccumulatorTest.java | 34 +- 22 files changed, 839 insertions(+), 324 deletions(-) diff --cc CHANGES.txt index 4a9ae14,9dbbd1c..e74f330 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,13 -1,11 +1,14 @@@ -3.11.8 +4.0-beta2 + * Forbid altering UDTs used in partition keys (CASSANDRA-15933) + * Fix version parsing logic when upgrading from 3.0 (CASSANDRA-15973) + * Optimize NoSpamLogger use in hot paths (CASSANDRA-15766) + * Verify sstable components on startup (CASSANDRA-15945) +Merged from 3.11: + * stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up (CASSANDRA-15191) * Frozen RawTuple is not annotated with frozen in the toString method (CASSANDRA-15857) Merged from 3.0: + * Operational improvements and hardening for replica filtering protection (CASSANDRA-15907) - * stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up (CASSANDRA-15191) - * Forbid altering UDTs used in partition keys (CASSANDRA-15933) * Fix empty/null json string representation (CASSANDRA-15896) - * 3.x fails to start if commit log has range tombstones from a column which is also deleted (CASSANDRA-15970) Merged from 2.2: * Fix CQL parsing of collections when the column type is reversed (CASSANDRA-15814) diff --cc build.xml index f0948ae,50d278e..d861920 --- a/build.xml +++ b/build.xml @@@ -556,15 -412,19 +556,14 @@@ - + - - - - - - - - + + + - - + diff --cc doc/source/operating/metrics.rst index fc37440,4bd0c08..0053cbc --- a/doc/source/operating/metrics.rst +++ b/doc/source/operating/metrics.rst @@@ -79,76 -75,65 +79,80 @@@ Reported name format **all** tables and keyspaces on the node. - === == === - NameType Description - === == === - MemtableOnHeapSize GaugeTotal amount of data stored in the memtable that resides **on**-heap, including column related overhead and partitions overwritten. - MemtableOffHeapSize GaugeTotal amount of data stored in the memtable that resides **off**-heap, including column related overhead and partitions overwritten. - MemtableLiveDataSizeGaugeTotal amount of live data stored in the memtable, excluding any data structure overhead. - AllMemtablesOnHeapSize GaugeTotal amount of data stored in the memtables (2i and pending flush memtables included) that resides **on**-heap. - AllMemtablesOffHeapSize GaugeTotal amount of data stored in the memtables (2i and pending flush memtables included) that resides **off**-heap. - AllMemtablesLiveDataSizeGaugeTotal amount of live data stored in the memtables (2i and pending flush memtables included) that resides off-heap, excluding any data structure overhead. - MemtableColumnsCountGaugeTotal
[cassandra] branch cassandra-3.11 updated (86b7727 -> 2ef1f1c)
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 86b7727 Merge branch 'cassandra-3.0' into cassandra-3.11
new e5c3d08 Operational improvements and hardening for replica filtering
protection patch by Caleb Rackliffe; reviewed by Andrés de la Peña for
CASSANDRA-15907
new 2ef1f1c Merge branch 'cassandra-3.0' into cassandra-3.11
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt| 1 +
build.xml | 2 +-
conf/cassandra.yaml| 20 +
doc/source/operating/metrics.rst | 114 +++---
src/java/org/apache/cassandra/config/Config.java | 2 +
.../cassandra/config/DatabaseDescriptor.java | 20 +
...java => ReplicaFilteringProtectionOptions.java} | 9 +-
.../db/partitions/PartitionIterators.java | 48 ++-
.../apache/cassandra/db/rows/EncodingStats.java| 24 ++
.../org/apache/cassandra/metrics/TableMetrics.java | 21 +-
.../org/apache/cassandra/service/DataResolver.java | 87 +++--
.../service/ReplicaFilteringProtection.java| 421 -
.../apache/cassandra/service/StorageService.java | 27 +-
.../cassandra/service/StorageServiceMBean.java | 12 +
.../org/apache/cassandra/utils/FBUtilities.java| 4 +-
.../cassandra/utils/concurrent/Accumulator.java| 9 +-
.../cassandra/distributed/impl/Coordinator.java| 10 +
.../apache/cassandra/distributed/impl/RowUtil.java | 7 +-
.../test/ReplicaFilteringProtectionTest.java | 244
.../cassandra/db/rows/EncodingStatsTest.java | 145 +++
.../utils/concurrent/AccumulatorTest.java | 34 +-
21 files changed, 959 insertions(+), 302 deletions(-)
copy src/java/org/apache/cassandra/config/{ReadRepairDecision.java =>
ReplicaFilteringProtectionOptions.java} (72%)
create mode 100644
test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java
create mode 100644
test/unit/org/apache/cassandra/db/rows/EncodingStatsTest.java
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2ef1f1c150e3d3f297e86c2b2efedd964a43b3c9 Merge: 86b7727 e5c3d08 Author: Caleb Rackliffe AuthorDate: Thu Jul 30 13:27:53 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt| 1 + build.xml | 2 +- conf/cassandra.yaml| 20 + doc/source/operating/metrics.rst | 114 +++--- src/java/org/apache/cassandra/config/Config.java | 2 + .../cassandra/config/DatabaseDescriptor.java | 20 + .../config/ReplicaFilteringProtectionOptions.java | 28 ++ .../db/partitions/PartitionIterators.java | 48 ++- .../apache/cassandra/db/rows/EncodingStats.java| 24 ++ .../org/apache/cassandra/metrics/TableMetrics.java | 21 +- .../org/apache/cassandra/service/DataResolver.java | 87 +++-- .../service/ReplicaFilteringProtection.java| 421 - .../apache/cassandra/service/StorageService.java | 27 +- .../cassandra/service/StorageServiceMBean.java | 12 + .../org/apache/cassandra/utils/FBUtilities.java| 4 +- .../cassandra/utils/concurrent/Accumulator.java| 9 +- .../cassandra/distributed/impl/Coordinator.java| 10 + .../apache/cassandra/distributed/impl/RowUtil.java | 7 +- .../test/ReplicaFilteringProtectionTest.java | 244 .../cassandra/db/rows/EncodingStatsTest.java | 145 +++ .../utils/concurrent/AccumulatorTest.java | 34 +- 21 files changed, 980 insertions(+), 300 deletions(-) diff --cc CHANGES.txt index 73f1a11,182dca3..9dbbd1c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,9 +1,11 @@@ -3.0.22: +3.11.8 + * Frozen RawTuple is not annotated with frozen in the toString method (CASSANDRA-15857) +Merged from 3.0: + * Operational improvements and hardening for replica filtering protection (CASSANDRA-15907) * stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up (CASSANDRA-15191) - * 3.x fails to start if commit log has range tombstones from a column which is also deleted (CASSANDRA-15970) * Forbid altering UDTs used in partition keys (CASSANDRA-15933) * Fix empty/null json string representation (CASSANDRA-15896) + * 3.x fails to start if commit log has range tombstones from a column which is also deleted (CASSANDRA-15970) Merged from 2.2: * Fix CQL parsing of collections when the column type is reversed (CASSANDRA-15814) diff --cc conf/cassandra.yaml index 9182008,bb96f18..29442f5 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@@ -1119,69 -996,6 +1119,89 @@@ enable_scripted_user_defined_functions # setting. windows_timer_interval: 1 + +# Enables encrypting data at-rest (on disk). Different key providers can be plugged in, but the default reads from +# a JCE-style keystore. A single keystore can hold multiple keys, but the one referenced by +# the "key_alias" is the only key that will be used for encrypt opertaions; previously used keys +# can still (and should!) be in the keystore and will be used on decrypt operations +# (to handle the case of key rotation). +# +# It is strongly recommended to download and install Java Cryptography Extension (JCE) +# Unlimited Strength Jurisdiction Policy Files for your version of the JDK. +# (current link: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html) +# +# Currently, only the following file types are supported for transparent data encryption, although +# more are coming in future cassandra releases: commitlog, hints +transparent_data_encryption_options: +enabled: false +chunk_length_kb: 64 +cipher: AES/CBC/PKCS5Padding +key_alias: testing:1 +# CBC IV length for AES needs to be 16 bytes (which is also the default size) +# iv_length: 16 +key_provider: + - class_name: org.apache.cassandra.security.JKSKeyProvider +parameters: + - keystore: conf/.keystore +keystore_password: cassandra +store_type: JCEKS +key_password: cassandra + + +# +# SAFETY THRESHOLDS # +# + +# When executing a scan, within or across a partition, we need to keep the +# tombstones seen in memory so we can return them to the coordinator, which +# will use them to make sure other replicas also know about the deleted rows. +# With workloads that generate a lot of tombstones, this can cause performance +# problems and even exaust the server heap. +# (http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets) +# Adjust the thresholds here if you understand the dangers and want to +# scan more tombstones anyway. These thresholds may also be adjusted
[cassandra] branch trunk updated (3e393f2 -> 292650d)
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 3e393f2 Merge branch 'cassandra-3.11' into trunk
new e5c3d08 Operational improvements and hardening for replica filtering
protection patch by Caleb Rackliffe; reviewed by Andrés de la Peña for
CASSANDRA-15907
new 2ef1f1c Merge branch 'cassandra-3.0' into cassandra-3.11
new 292650d Merge branch 'cassandra-3.11' into trunk
The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt| 1 +
build.xml | 3 +-
conf/cassandra.yaml| 20 +
doc/source/operating/metrics.rst | 144 +++
src/java/org/apache/cassandra/config/Config.java | 2 +
.../cassandra/config/DatabaseDescriptor.java | 20 +
...java => ReplicaFilteringProtectionOptions.java} | 17 +-
.../db/partitions/PartitionIterators.java | 47 +++
.../org/apache/cassandra/metrics/TableMetrics.java | 21 +-
.../apache/cassandra/service/StorageService.java | 28 +-
.../cassandra/service/StorageServiceMBean.java | 12 +
.../cassandra/service/reads/DataResolver.java | 57 ++-
.../service/reads/ReplicaFilteringProtection.java | 444 -
.../reads/ShortReadPartitionsProtection.java | 10 +-
.../service/reads/ShortReadProtection.java | 17 +-
.../service/reads/repair/NoopReadRepair.java | 3 +-
.../org/apache/cassandra/transport/Message.java| 2 +-
.../cassandra/utils/concurrent/Accumulator.java| 9 +-
.../cassandra/distributed/impl/Coordinator.java| 10 +
.../apache/cassandra/distributed/impl/RowUtil.java | 7 +-
.../test/ReplicaFilteringProtectionTest.java | 244 +++
.../utils/concurrent/AccumulatorTest.java | 34 +-
22 files changed, 818 insertions(+), 334 deletions(-)
copy src/java/org/apache/cassandra/config/{ConfigurationLoader.java =>
ReplicaFilteringProtectionOptions.java} (69%)
create mode 100644
test/distributed/org/apache/cassandra/distributed/test/ReplicaFilteringProtectionTest.java
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Operational improvements and hardening for replica filtering protection patch by Caleb Rackliffe; reviewed by Andrés de la Peña for CASSANDRA-15907
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new e5c3d08 Operational improvements and hardening for replica filtering protection patch by Caleb Rackliffe; reviewed by Andrés de la Peña for CASSANDRA-15907 e5c3d08 is described below commit e5c3d08a1428d378b6690f0419a2b25724b9736e Author: Caleb Rackliffe AuthorDate: Mon Jun 29 13:54:23 2020 -0500 Operational improvements and hardening for replica filtering protection patch by Caleb Rackliffe; reviewed by Andrés de la Peña for CASSANDRA-15907 --- CHANGES.txt| 1 + build.xml | 2 +- conf/cassandra.yaml| 20 + src/java/org/apache/cassandra/config/Config.java | 2 + .../cassandra/config/DatabaseDescriptor.java | 20 + .../config/ReplicaFilteringProtectionOptions.java | 28 ++ .../db/partitions/PartitionIterators.java | 49 ++- .../partitions/UnfilteredPartitionIterators.java | 19 - .../apache/cassandra/db/rows/EncodingStats.java| 24 ++ .../org/apache/cassandra/metrics/TableMetrics.java | 22 +- .../org/apache/cassandra/service/DataResolver.java | 89 +++-- .../service/ReplicaFilteringProtection.java| 423 - .../apache/cassandra/service/StorageService.java | 27 +- .../cassandra/service/StorageServiceMBean.java | 12 + .../org/apache/cassandra/utils/FBUtilities.java| 4 +- .../cassandra/utils/concurrent/Accumulator.java| 9 +- .../cassandra/distributed/impl/Coordinator.java| 10 + .../apache/cassandra/distributed/impl/RowUtil.java | 7 +- .../test/ReplicaFilteringProtectionTest.java | 244 .../cassandra/db/rows/EncodingStatsTest.java | 145 +++ .../utils/concurrent/AccumulatorTest.java | 34 +- 21 files changed, 924 insertions(+), 267 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index a755b7e..182dca3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.22: + * Operational improvements and hardening for replica filtering protection (CASSANDRA-15907) * stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up (CASSANDRA-15191) * 3.x fails to start if commit log has range tombstones from a column which is also deleted (CASSANDRA-15970) * Forbid altering UDTs used in partition keys (CASSANDRA-15933) diff --git a/build.xml b/build.xml index 6492767..6c1d148 100644 --- a/build.xml +++ b/build.xml @@ -398,7 +398,7 @@ - + diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index c321a72..bb96f18 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -661,6 +661,26 @@ auto_snapshot: true tombstone_warn_threshold: 1000 tombstone_failure_threshold: 10 +# Filtering and secondary index queries at read consistency levels above ONE/LOCAL_ONE use a +# mechanism called replica filtering protection to ensure that results from stale replicas do +# not violate consistency. (See CASSANDRA-8272 and CASSANDRA-15907 for more details.) This +# mechanism materializes replica results by partition on-heap at the coordinator. The more possibly +# stale results returned by the replicas, the more rows materialized during the query. +replica_filtering_protection: +# These thresholds exist to limit the damage severely out-of-date replicas can cause during these +# queries. They limit the number of rows from all replicas individual index and filtering queries +# can materialize on-heap to return correct results at the desired read consistency level. +# +# "cached_replica_rows_warn_threshold" is the per-query threshold at which a warning will be logged. +# "cached_replica_rows_fail_threshold" is the per-query threshold at which the query will fail. +# +# These thresholds may also be adjusted at runtime using the StorageService mbean. +# +# If the failure threshold is breached, it is likely that either the current page/fetch size +# is too large or one or more replicas is severely out-of-sync and in need of repair. +cached_rows_warn_threshold: 2000 +cached_rows_fail_threshold: 32000 + # Granularity of the collation index of rows within a partition. # Increase if your rows are large, or if you have a very large # number of rows per partition. The competing goals are these: diff --git a/src/java/org/apache/cassandra/config/Config.java b/src/java/org/apache/cassandra/config/Config.java index 6003bd1..2218ee2 100644 --- a/src/java/org/apache/cassandra/config/Config.java +++ b/src/java/org/apache/cassandra/config/Config.java @@ -280,6 +280,8 @@ public class Config public volatile int
[jira] [Commented] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167880#comment-17167880 ] Berenguer Blasi commented on CASSANDRA-15583: - Update: I expect CASSANDRA-15991 to go into review soon. After several days adding UTs just for the smaller tools and just sanity checking their input args on a happy path, I've come to realize this task is even bigger, fiddlier and brittler than you can imagine: * UT has been added for basic sanity checking params to not fail the tool. Some broken or missing options in docs have been found. I intend to fix those in an upcoming ticket. * Just adding proper UT for params (boundary, poisoned, random,... params) would entail _a lot_ of work as many tools work only on the happy path but crash otherwise. So there is a lot of hidden cost fixing the tools as you add new test cases. I.e. negative numbers for a 'size' and similar input validation/guardrails * If we got to have good params UT, then you'd have to focus on that tool specifics and UT it as most have 0% coverage atm. That again is a huge task bigger than the 2 before this one. * Then there are the big ones: nodetool, cassandra-stress, cqlsh... which again are on their own bigger than the 3 before this one. Currently 15583 seeds and unblocks tooling testing. But providing good UT for all tools would imply a multi-month effort and I don't dislike anybody that much to whish him work on that after my recent experience lol. Here is what I intend to do: # Fix the broken options and docs # Create tickets to UT each tool and flag them LHF if applicable imo # Create tickets for the bigger tools With that we can scope tickets in/out at a doable pace + newcomers can help with the LHF ones. That leaves 15583 more as a seeding/unblocking & surface area discovery ticket for UT tooling than actually _solving_ it. So I don't know what was the original spirit of the ticket and if it makes sense to close it or not? See CASSANDRA-15991 PR for details. I'll ping when it's ready for review so we can merge. > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest, Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). > ||Tool||UX test||UT coverage||dtest coverage||Comments|| > |Nodetool|(x)|(x)|(!)|Deserves it's own ticket. Not all the sub commands are > tested. Dtest also test nodetool as a side effect| > |Cqlsh|(x)|(x)|(!)|Deserves it's own ticket| > |Cassandra-stress|(x)|(x)|(x)|Some UT. Deserves it's own ticket| > |debug-cql|(x)|(x)|(x)|Deserves it's own ticket | > |fqltool|(x)|(/)|(!)|Deserves it's own ticket | > |auditlogviewer|(/)|(!)|(!)|UX tests: C-15991. Docs missing option -i| > |*Sstable utilities*| | | | | > |sstabledump|(/)|(x)|(!)|UX tests: C-15991| > |sstableexpiredblockers|(/)|(x)|(!)|UX tests: C-15991| > |sstablelevelreset|(/)|(x)|(!)|UX tests: C-15991| > |sstableloader|(x)|(x)|(!)|Needs it's own ticket probably| > |sstablemetadata|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, missing options in docs, brittle args parsing| > |sstableofflinerelevel|(/)|(x)|(!)|UX tests: C-15991, brittle args parsing| > |sstablerepairedset|(/)|(x)|(x)|Ran in dtests, no dedicated test, UX tests: > C-15991, brittle args parsing| > |sstablescrub|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs| > |sstablesplit|(/)|(x)|(!)|UX tests: C-15991| > |sstableupgrade|(/)|(x)|(!)|UX tests: C-15991| > |sstableutil|(/)|(x)|(!)|UX tests: C-15991| > |sstableverify|(/)|(x)|(!)|UX tests: C-15991 but missing options in docs + > broken token_range option| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15991) 15583 - Add UX tests to intree LHF tooling
[ https://issues.apache.org/jira/browse/CASSANDRA-15991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167856#comment-17167856 ] Berenguer Blasi commented on CASSANDRA-15991: - This PR seeds most cmd line tools in terms of args parsing unit testing. Bigger tools like nodetool will have their own ticket to address all unit testing matters there. This is the first baby step of the 'big unit testing tooling' effort in CASSANDRA-15583 > 15583 - Add UX tests to intree LHF tooling > -- > > Key: CASSANDRA-15991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15991 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > As per CASSANDRA-15583 many in tree tools lack proper UX tooling: mandatory > params are indeed mandatory, 'help' produces an actual help, return codes etc > This ticket is an attempt to add it to those tools that classify as LHF. > Other tools such as nodetool, with many sub-commands, deserve a separate > ticket of their own -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15166) Cassandra startup error
[ https://issues.apache.org/jira/browse/CASSANDRA-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167838#comment-17167838 ] sunil commented on CASSANDRA-15166: --- Hi [~ifesdjeen], I have attached system and debug traces. Please suggest. > Cassandra startup error > --- > > Key: CASSANDRA-15166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15166 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: abalakrishna >Priority: Normal > Attachments: debug.log, system.log > > > We have Cassandra cluster with three nodes installed in ubuntu, > We are getting below startup error while restarting ,same error for all the > three nodes. > Can anyone please help with the solution to start the Cassandra back. > ERROR > *ERROR [main] CassandraDaemon.java:731 - Exception encountered during startup* > *java.lang.IllegalArgumentException: c997e340-2939-11e9-bf8c-edeff921e924 is > already bound in reverseMap to (cli_150,_track)* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15166) Cassandra startup error
[ https://issues.apache.org/jira/browse/CASSANDRA-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunil updated CASSANDRA-15166: -- Attachment: debug.log > Cassandra startup error > --- > > Key: CASSANDRA-15166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15166 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: abalakrishna >Priority: Normal > Attachments: debug.log, system.log > > > We have Cassandra cluster with three nodes installed in ubuntu, > We are getting below startup error while restarting ,same error for all the > three nodes. > Can anyone please help with the solution to start the Cassandra back. > ERROR > *ERROR [main] CassandraDaemon.java:731 - Exception encountered during startup* > *java.lang.IllegalArgumentException: c997e340-2939-11e9-bf8c-edeff921e924 is > already bound in reverseMap to (cli_150,_track)* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15166) Cassandra startup error
[ https://issues.apache.org/jira/browse/CASSANDRA-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunil updated CASSANDRA-15166: -- Attachment: system.log > Cassandra startup error > --- > > Key: CASSANDRA-15166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15166 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: abalakrishna >Priority: Normal > Attachments: system.log > > > We have Cassandra cluster with three nodes installed in ubuntu, > We are getting below startup error while restarting ,same error for all the > three nodes. > Can anyone please help with the solution to start the Cassandra back. > ERROR > *ERROR [main] CassandraDaemon.java:731 - Exception encountered during startup* > *java.lang.IllegalArgumentException: c997e340-2939-11e9-bf8c-edeff921e924 is > already bound in reverseMap to (cli_150,_track)* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15166) Cassandra startup error
[ https://issues.apache.org/jira/browse/CASSANDRA-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167830#comment-17167830 ] sunil commented on CASSANDRA-15166: --- Am also facing the same issue. As am trying out this with two node cluster and my both nodes are not coming up due to the same error. Please suggest. > Cassandra startup error > --- > > Key: CASSANDRA-15166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15166 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: abalakrishna >Priority: Normal > > We have Cassandra cluster with three nodes installed in ubuntu, > We are getting below startup error while restarting ,same error for all the > three nodes. > Can anyone please help with the solution to start the Cassandra back. > ERROR > *ERROR [main] CassandraDaemon.java:731 - Exception encountered during startup* > *java.lang.IllegalArgumentException: c997e340-2939-11e9-bf8c-edeff921e924 is > already bound in reverseMap to (cli_150,_track)* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167817#comment-17167817
]
Andres de la Peña commented on CASSANDRA-15907:
---
Great, ci-cassandra looks good too:
||branch||utest||dtest||
|
[3.0|https://github.com/apache/cassandra/pull/659]|[200|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-test/200]|[236|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/236]|
|
[3.11|https://github.com/apache/cassandra/pull/665]|[201|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-test/201]|[237|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/237]|
|[trunk|https://github.com/apache/cassandra/pull/666]|[202|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-test/202]|[238|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/238]|
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15907:
--
Status: Ready to Commit (was: Review In Progress)
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15999) Cassandra 3.0.21 debian package is half available
Brice Figureau created CASSANDRA-15999:
--
Summary: Cassandra 3.0.21 debian package is half available
Key: CASSANDRA-15999
URL: https://issues.apache.org/jira/browse/CASSANDRA-15999
Project: Cassandra
Issue Type: Bug
Components: Packaging
Reporter: Brice Figureau
Hi,
Cassandra 3.0.21 seems to have been released in the debian package repository,
as it is selected by an {{apt install cassandra}} however the {{.deb}} is not
available in the repository (only the {{.dsc}}):
{code:java}
# apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
cassandra-tools
The following packages will be upgraded:
cassandra cassandra-tools
2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
Need to get 25.5 MB/25.5 MB of archives.
After this operation, 37.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Ign:1 https://dl.bintray.com/apache/cassandra 30x/main amd64 cassandra all
3.0.21
Err:1 http://www.apache.org/dist/cassandra/debian 30x/main amd64 cassandra all
3.0.21
404 Not Found [IP: 52.58.94.94 443]
E: Failed to fetch
http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb
404 Not Found [IP: 52.58.94.94 443]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?
{code}
Indeed, there's no
{{https://dl.bintray.com/apache/cassandra/dist/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.21_all.deb}}
file avaible.
{{cassandra-tools}} 3.0.21 is available, and of course {{cassandra}} 3.0.20 is
available though.
My current workaround is to use apt-pinning to pin to 3.0.20 until the problem
is resolved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
