Cassandra и Java 9 - ThreadPriorityPolicy = 42 находится за пределами допустимого диапазона

Совсем недавно я установил JDK 9 и Apache Cassandra с официального сайта. Но теперь, когда я начинаю кассандру на переднем плане, я получаю это сообщение:

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.

До сих пор я не нашел для этого никакого решения. Возможно ли, что Java 9 и Cassandra еще не совместимы? Здесь также упоминается проблема - # CASSANDRA-13107

Но я не уверен, как просто "удалить флаг"? Где можно переопределить или удалить этот флаг?

Ответы

Ответ 1

У меня была точно такая же проблема: Не удается запустить Cassandra (Single- Node Cluster на CentOS7)

Если это вариант для вас, использование Java 8 вместо 9 - это самый простой способ решить проблему.

Ответ 2

@Martin Matak Просто закомментируйте эту строку в файле conf/jvm.options:

########################
# 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

Установка следующих переменных env решила проблему в 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 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

Решение вашего вопроса

Причина этого исключения

Несколько версий JDK, работающих, вероятно, JDK9, JDK 10 вызывает это исключение.
Установите только путь Path to Point JDK 8.
В настоящее время желательно, чтобы cassandra 3.1 работала больше, чем jdk 8.

Изменение в файле Cassandra-Conf (/opt/apache-cassandra-3.11.2/conf/cassandra-env.sh)

4. Если вы хотите использовать более высокую версию JDK, обновите системные переменные пути в зависимости от вашей ОС.

Ответ 5

Theres a jvm.options в вашем каталоге conf, который устанавливает его:

https://github.com/apache/cassandra/blob/12d4e2f189fb228250edc876963d0c74b5ab0d4f/conf/jvm.options#L96

Ответ 6

Следуя ответу Джея, ответьте, если вы работаете в macOS и установлены через Homebrew: файл находится в local/etc/cassandra/jvm.options.

Ответ 7

Немного предыстории -XX:ThreadPriorityPolicy.

Это были значения, как указано в исходном коде.

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.

Другими словами: Стандартная настройка по умолчанию заставляет приоритеты потоков игнорироваться в Linux.

Теперь кто-то обнаружил в коде ошибку, из-за которой отключено "Является ли root?" проверить значения, отличные от 1, но все равно попытаться установить приоритет потока для каждого значения, отличного от 0.

Если он не работает от имени пользователя root, будет возможно только снизить приоритет потока. Таким образом, хотя это и не идеально, это было довольно значительным улучшением по сравнению с невозможностью контролировать приоритеты вообще.

Начиная с Java 9, аргументы командной строки, подобные этому, начали проверяться checked, и этот хак перестал работать.

Между прочим, в Java 11/Linux я могу установить параметр на 1, не будучи root, и установка приоритетов потоков имеет эффект. Так что за это время что-то изменилось, и, по крайней мере, с недавними JVM, и этот взлом больше не кажется необходимым.