Estamos planeando migrar nuestro entorno de Java 8 a OpenJDK 10. Al hacer esto en mi máquina local, descubrí que Cassandra ya no se iniciará por mí, dando el siguiente error:

enter image description here

No puedo encontrar ninguna información sólida en línea que diga que definitivamente no es compatible.

Esta publicación de hace 4 meses sugiere que no son compatibles con Java 10 , pero no dice que esté confirmado, y se infiere más. También hay un comentario de otro usuario que dice que han logrado ejecutarlo en Java 11.

El comentario final sobre este ticket en datastax dice "Hemos actualizado nuestra matriz CI para incluir Java 10 y todo funciona, excepto los problemas de prueba OSGi mencionados anteriormente ". No estoy seguro de qué sacar de eso, pero parece implicar que está funcionando con Java 10 ahora, ya que el ticket está marcado como resuelto.

Este ticket, discuten el soporte para Java 11. Hay algunos comentarios que discuten el incluso necesitan ser compatibles con Java 10, pero en realidad no dan una respuesta definitiva sobre si lo harán o no.

Finalmente, este blog analiza una forma de hacer que Java 11 funcione con cassandra. Sin embargo, noto que esto está usando Cassandra 4.0. ¿Se ha lanzado oficialmente esto? Noto en su sitio web que dicen que la fecha de lanzamiento es tbd y dice que la versión estable actual es 3.11.3 , y no se menciona en su página de compatibilidad.

Actualmente instalé Cassandra en Windows a través de Datastax, pero también intenté clonar el repositorio git actual y ejecutarlo desde allí, pero recibo el mismo mensaje de error (aunque en su github parecen decir que solo se ha probado con Java 8 )

¿Simplemente no admiten 10 entonces? Además, si alguien sabe si planean lanzar 4.0 pronto, y si eso definitivamente admitirá 11 (¿y supongo que 10?), Sería una gran ayuda.

11
user3275784 14 sep. 2018 a las 18:04

4 respuestas

La mejor respuesta

Cassandra 4.0 tiene soporte explícito para Java 8 y Java 11. De hecho, incluso dividieron los archivos de configuración como tales:

$ pwd
/Users/aaron/local/apache-cassandra-4.0-SNAPSHOT/conf
$ ls -a jvm*
jvm-clients.options jvm11-clients.options   jvm8-clients.options
jvm-server.options  jvm11-server.options    jvm8-server.options

La razón para el soporte de estas versiones específicas es doble. En primer lugar, Java 8 ha sido el estándar de facto para Cassandra durante algunos años. Los usuarios esperan que siga funcionando en Java 8 en el futuro.

Dado el nuevo ciclo de lanzamiento de 6 meses de Java, Java 9 y Java 10 ya no serán "actuales" cuando aparezca Apache Cassandra 4.0. Además, las pruebas que se ejecutan durante la compilación han demostrado ser exigentes con respecto a la versión de Java con la que trabajan. Por lo tanto, se tomó la decisión de admitir Java 8 y 11 para 4.0, ya que el trabajo en Java 9 y 10 parecía tener menor prioridad.

Eso no quiere decir que Cassandra 4.0 no se ejecutará en Java 9 o 10. De hecho, CASSANDRA-9608 incluso tiene un parche enviado que debería cubrirlo. Pero el hecho es que Java 8 está incluido debido a su uso de larga data en la base de usuarios de Cassandra. Java 11 será el JDK / JRE actual en el momento de las versiones 4.0. Si quiere estar seguro de que su clúster funcionará bien, elegiría uno de esos dos.

Pero hasta 4.0, el parche más reciente de Java 8 es realmente la única opción.

16
Aaron 14 sep. 2018 a las 16:18

A partir de ahora, Cassandra 3.x solo funcionará con Java 8. Cassandra 4.0 es compatible con Java 8 y Java 11, pero aún no se ha lanzado al momento de escribir esta respuesta.

Si desea ejecutar Cassandra en su sistema local (no recomendado para producción) con java 11. Luego puede seguir estos pasos:

Requisito previo: Java 11, Apache Ant, Python

  1. Descargue el código de rama de Cassandra: https://github.com/apache/cassandra

  2. Descomprima el archivo y abra la carpeta en el terminal / símbolo del sistema.

  3. Construya cassandra con -Duse.jdk11 = argumento verdadero:
ajit-soman@ajitsoman-X542BA:~/Downloads/cassandra-trunk$ ant -Duse.jdk11=true
Buildfile: /home/ajit-soman/Downloads/cassandra-trunk/build.xml
   [script] Warning: Nashorn engine is planned to be removed from a future JDK release
...
...
jar:
[mkdir] Created dir: /home/ajit-soman/Downloads/cassandra-trunk/build/classes/stress/META-INF
[mkdir] Created dir: /home/ajit-soman/Downloads/cassandra-trunk/build/tools/lib
  [jar] Building jar: /home/ajit-soman/Downloads/cassandra-trunk/build/tools/lib/stress.jar
[mkdir] Created dir: /home/ajit-soman/Downloads/cassandra-trunk/build/classes/fqltool/META-INF
  [jar] Building jar: /home/ajit-soman/Downloads/cassandra-trunk/build/tools/lib/fqltool.jar

BUILD SUCCESSFUL
Total time: 7 minutes 38 seconds
  1. Navegue a la carpeta bin y ejecute Cassandra:
ajit-soman@ajitsoman-X542BA:~/Downloads/cassandra-trunk/bin$ ./cassandra 
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
CompileCommand: dontinline
  1. Verificar el estado de la herramienta de nodo
ajit-soman@ajitsoman-X542BA:~/Downloads/cassandra-trunk/bin$ ./nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load      Tokens  Owns (effective)  Host ID                               Rack 
UN  127.0.0.1  5.79 KiB  256     100.0%            68687cfd-a80b-45db-93cd-7bc2d212a64b  rack1
  1. Ejecute cqlsh
ajit-soman@ajitsoman-X542BA:~/Downloads/cassandra-trunk/bin$ ./cqlsh 
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 4.0-alpha2-SNAPSHOT | CQL spec 3.4.5 | Native protocol v4]
Use HELP for help.
cqlsh> 
0
Ajit Soman 3 oct. 2019 a las 17:51

Las versiones lanzadas de Cassandra solo admiten Java 8: la compatibilidad con versiones superiores estará en Cassandra 4.0 que aún no se ha lanzado. Puede seguir el progreso en el CASSANDRA-9608

6
Alex Ott 14 sep. 2018 a las 15:59

Con Cassandra 3.11.4 hemos podido ejecutar el motor Cassandra con Java 11, pero ha habido algunos problemas:

  • Si por alguna razón todavía está usando CMS para la recolección de basura, sería el momento de pasar a G1; esto se configura en el archivo jvm.options.
  • También en jvm.options, deberá deshabilitar ThreadPriorityPolicy ya que se desactivó con Java 9
  • Con el registro unificado de la actividad de gc, introducido con Java 9, deberá eliminar los parámetros específicos de gc en jvm.options. Algunos de esos parámetros son:
    • -Xloggc
    • -XX: + PrintGCDetails
    • -XX: + PrintGCDateStamps
    • -XX: + PrintHeapAtGC
    • -XX: + PrintTenuringDistribution
    • -XX: + PrintGCApplicationStoppedTime
    • -XX: + PrintPromotionFailure
  • nodetool todavía requiere Java 8 para poder ejecutarse.

    • Tenemos ambos JVM instalados y utilizamos alternativas para configurar Java 11 como predeterminado. Este es también el valor de la variable JAVA_HOME
    • Tenemos una nueva variable llamada JAVA8_HOME que apunta a esa versión
    • Actualizamos el script de nodetool (en nuestro caso estaba en / usr / bin / nodetool) para usar JAVA8_HOME al configurar la variable JAVA
  • Para un clúster que estaba usando offheap_buffers para memtable_allocation_type (se define en cassandra.yaml), tuvimos que cambiarlo para usar offheap_objects

4
Carlos Monroy Nieblas 10 abr. 2019 a las 19:50