[
https://issues.apache.org/jira/browse/CASSANDRA-19818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872338#comment-17872338
]
Stefan Miklosovic commented on CASSANDRA-19818:
-----------------------------------------------
well I am taking it back, I think we have a problem.
https://app.circleci.com/pipelines/github/instaclustr/cassandra/4587/workflows/195383b6-0f94-47b1-906f-ba580d72b472/jobs/261197/tests#failed-test-4
I was thinking these tests are failing / are flaky but they actually introduces
a change which fails them. That is legit error we need to deal with.
{code}
[junit-timeout] junit.framework.AssertionFailedError: Property error detected:
[junit-timeout] Seed = 8335649466716534365
[junit-timeout] Examples = 10
[junit-timeout] Pure = false
[junit-timeout] Error: Rejecting access
[junit-timeout] Values:
[junit-timeout] 0 = accord.utils.DefaultRandom@5bd191c2
[junit-timeout]
[junit-timeout] at
accord.utils.Property$SingleBuilder.checkInternal(Property.java:242)
[junit-timeout] at
accord.utils.Property$SingleBuilder.check(Property.java:226)
[junit-timeout] at
accord.utils.Property$ForBuilder.check(Property.java:124)
[junit-timeout] at
org.apache.cassandra.repair.SlowMessageFuzzTest.slowMessages(SlowMessageFuzzTest.java:41)
[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.IllegalStateException: Rejecting access
[junit-timeout] at
org.apache.cassandra.repair.FuzzTestBase$ClockAccess.checkAccess(FuzzTestBase.java:1477)
[junit-timeout] at
org.apache.cassandra.repair.FuzzTestBase$ClockAccess.nanoTime(FuzzTestBase.java:1423)
[junit-timeout] at
org.apache.cassandra.utils.Clock$Global.nanoTime(Clock.java:100)
[junit-timeout] at
org.apache.cassandra.repair.consistent.LocalSessions.start(LocalSessions.java:357)
[junit-timeout] at
org.apache.cassandra.service.ActiveRepairService.start(ActiveRepairService.java:265)
[junit-timeout] at
org.apache.cassandra.repair.FuzzTestBase$Cluster$Node.<init>(FuzzTestBase.java:1134)
[junit-timeout] at
org.apache.cassandra.repair.FuzzTestBase$Cluster.<init>(FuzzTestBase.java:753)
[junit-timeout] at
org.apache.cassandra.repair.SlowMessageFuzzTest.lambda$slowMessages$1(SlowMessageFuzzTest.java:43)
[junit-timeout] at
accord.utils.Property$SingleBuilder.checkInternal(Property.java:238)
{code}
Check
{code}
at
org.apache.cassandra.repair.consistent.LocalSessions.start(LocalSessions.java:357)
{code}
That is what we added and it fails there.
> Minor improvements in Cassandra shutdown and startup logs
> ---------------------------------------------------------
>
> Key: CASSANDRA-19818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19818
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To improve a DBA experience the following log messages would be nice to
> add/adjust:
> * on shutdown: an explicit message at the end of Cassandra shutdown
> * on startup:
> ** print the time spent to load prepared statements
> ** print the time spent to load repair session information and the number of
> loaded session records
> ** print the time spent to apply commit log
> It would help with assessment of possible delays in startup/shutdown of
> Cassandra. For example, recently I observed a delay in Cassandra startup and
> from logs it was not clear was it caused by loading of prepared statements or
> repair service init.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
