[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792275#comment-17792275
]
Ekaterina Dimitrova edited comment on CASSANDRA-19001 at 12/19/23 12:23 AM:
----------------------------------------------------------------------------
Thanks [~Bereng]. I also do not see how this patch can trigger the error; the
question is whether there might be some bug in general and whether we need a
ticket to investigate further.
Looking into the logs, it seems like, as per
[this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java#L82]
formula, the only way to see that message is if the current time is
inaccurate. What bugs me is that the logger we use and the mentioned formula
both use System.currentTimeMillis(), so I am not sure what happened... the logs
seem to have the correct timing.
Another observation - we say in the test we set CAP policy, but then we end up
with rejection. The logs show that the test failed with "should not throw
InvalidRequest." So internally, the policy needed to be appropriately set to
CAP when Cassandra started, but we were throwing IRE, which, from what I saw,
is attributed to the wrong current time.
At the same time, I found in node1 log from the logs where the test failed:
{code:java}
-Dcassandra.expiration_date_overflow_policy=CAP{code}
We do not see [this
warning|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java#L60]
in the logs.
Shall we open a ticket, or am I missing anything?
I also made a run in a loop of the test:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2594/workflows/81a5d412-8ce0-4914-83a6-ca6f984fb7ab/jobs/50164/artifacts]
(finished green)
Plus, running the whole class in a loop:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2595/workflows/1b438226-496b-4000-bce5-dc9e73b48460/jobs/50269/parallel-runs/0?filterBy=ALL]
-(still running)- (finished green)
Let's see.
was (Author: e.dimitrova):
Thanks [~Bereng]. I also do not see how this patch can trigger the error; the
question is whether there might be some bug in general and whether we need a
ticket to investigate further.
Looking into the logs, it seems like, as per
[this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java#L82]
formula, the only way to see that message is if the current time is
inaccurate. What bugs me is that the logger we use and the mentioned formula
both use System.currentTimeMillis(), so I am not sure what happened... the logs
seem to have the correct timing.
Another observation - we say in the test we set CAP policy, but then we end up
with rejection. The logs show that the test failed with "should not throw
InvalidRequest." So internally, the policy needed to be appropriately set to
CAP when Cassandra started, but we were throwing IRE, which, from what I saw,
is attributed to the wrong current time.
At the same time, I found in node1 log from the logs where the test failed:
{code:java}
-Dcassandra.expiration_date_overflow_policy=CAP{code}
We do not see [this
warning|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java#L60]
in the logs.
Shall we open a ticket, or am I missing anything?
I also made a run in a loop of the test:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2594/workflows/81a5d412-8ce0-4914-83a6-ca6f984fb7ab/jobs/50164/artifacts]
(finished green)
Plus, running the whole class in a loop:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2595/workflows/1b438226-496b-4000-bce5-dc9e73b48460/jobs/50269/parallel-runs/0?filterBy=ALL]
(still running)
Let's see.
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Ekaterina Dimitrova
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
