Cassandra and Java 9 - ThreadPriorityPolicy=42 is outside the allowed range

问题

Very recently I installed JDK 9 and Apache Cassandra from the official site. But now when I start cassandra in foreground, I get this message:

apache-cassandra-3.11.1/bin$ ./cassandra -f

[0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:/home/mmatak/monero/apache-cassandra-3.11.1/logs/gc.log instead.
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Improperly specified VM option 'ThreadPriorityPolicy=42'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

So far I didn't find any solution for this. Is it maybe possible that Java 9 and Cassandra are not yet compatible? Here is that problem mentioned as well - #CASSANDRA-13107

But I am not sure how to just "remove the flag"? Where is it possible to override or remove this flag?

回答1:

I had exactly the same issue: Can't start Cassandra (Single-Node Cluster on CentOS7)

If it is an option for you, using Java 8, instead of 9, is the simplest way to solve the issue.

回答2:

@Martin Matak Just comment out that line in the conf/jvm.options file:

########################
# GENERAL JVM SETTINGS #
########################



# allows lowering thread priority without being root on linux - probably
# not necessary on Windows but doesn't harm anything.
# see http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html
**#-XX:ThreadPriorityPolicy=42**

回答3:

Setting the following env variables solved the problem in MAC export JAVA8_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home

回答4:

Solution to your Question

Reason for this exception

Multiple JDK versions running,probably JDK9,JDK 10 is causing this exception.
Set the Path to Point JDK 8 Version only.
Currently cassandra 3.1 is desired to run greater than jdk 8 only.

Change in Cassandra-Conf file (/opt/apache-cassandra-3.11.2/conf/cassandra-env.sh)

4.If you want to use higher JDK Version, update the system path variables based on your OS.

回答5:

Some background on -XX:ThreadPriorityPolicy.

These were the values, as documented in the source code.

0 : Normal.
    VM chooses priorities that are appropriate for normal
    applications. On Solaris NORM_PRIORITY and above are mapped
    to normal native priority. Java priorities below
    NORM_PRIORITY map to lower native priority values. On
    Windows applications are allowed to use higher native
    priorities. However, with ThreadPriorityPolicy=0, VM will
    not use the highest possible native priority,
    THREAD_PRIORITY_TIME_CRITICAL, as it may interfere with
    system threads. On Linux thread priorities are ignored
    because the OS does not support static priority in
    SCHED_OTHER scheduling class which is the only choice for
    non-root, non-realtime applications.
1 : Aggressive.
    Java thread priorities map over to the entire range of
    native thread priorities. Higher Java thread priorities map
    to higher native thread priorities. This policy should be
    used with care, as sometimes it can cause performance
    degradation in the application and/or the entire system. On
    Linux this policy requires root privilege.

In other words: The default Normal setting causes thread priorities to be ignored on Linux.

Now someone found a bug in the code, which disabled the "is root?" check for values other than 1, but would still try to set the thread priority for every value other than 0.

Unless running as root, it would only be possible to lower the thread priority. So although not perfect, this was quite an improvement, compared to not being able to control the priorities at all.

Starting with Java 9, command line arguments like this one started to get checked, and this hack stopped working.

Fwiw, on Java 11/Linux, I can set the parameter to 1 without being root, and setting thread priorities does have an effect. So something has changed in the meantime, and at least with recent JVMs, and this hack does not seem necessary any more.