Problemas generales

Problemas con RMI Excecutor

vmente normalmente, Luego de algún tiempo la ejecución de los flujos se detiene, RMI Excecutor parece no iniciar. Al hacer un “sudo reboot” el servidor vuelve al normal y el RMI se ejecuta bien.

Organizaciones afectadas:

  1. Marco KMT

  2. HupData

Procedimiento de solución:

El problema inicia luego de actualizar KNIME Server a la versión 4.11.4; Se ha realizado este procedimiento remplazando el archivo .war por un nuevo .war y borrando el anterior en el directorio webapps al interior de knime

Luego se ha actualizado el KNIME Excecutor a la versión 4.1.4 que es compatible con la 4.11.4 de KNIME Server y Se realizó descargando el Executor 4.1.4 tar.gz y luego efectuando el proceso de descompresión de este archivo

Se ha renombrado el directorio "knime_executor" bajo el directorio de knime_server como "knime_executor_old" y se colocó el executor 4.1.4 en su lugar.

Después de que se ha confirmado que el Servidor y el Excecuytor están configurados adecuadamente, hemos agregado la siguiente línea al archivo /workflow_repository/conf/knime-server.config:

com.knime.server.job.save_workflow_summary=falso

Notas sobre la solución temporal:

Esta configuración en false se ha identificado como causante del problema, el cual ha estado ocurriendo debido a que el workflow_summary puede llegar a tomar mucho tiempo en generarse después de que el flujo de trabajo se ejecuta, llevando al congelamiento del servidor.

Se puede consultar más acerca de la funcionalidad workflow_summary en https://www.knime.com/blog/compliance-and-explainability-with-metadata-mapping

Esta pendiente la solución definitiva, luego que el departamento de soporte de KNIME revise los LOG del servidor.

Textos originales:

  1. Comenzó actualizando la aplicación KNIME Server a 4.11.4

  • Hice esto reemplazando el archivo .war con el nuevo archivo .war y eliminando la carpeta anterior existente en el directorio de Webapps llamado knime

  • Luego actualizamos KNIME Executor a la versión 4.1.4 para que sea compatible con el servidor 4.11.4

  • Hice esto descargando el archivo 4.1.4 Executor tar.gz y descomprimiéndolo

  • Luego cambiamos el nombre de la carpeta anterior "knime_executor" en /knime_server/ a "knime_executor_old, y cambiamos el nombre del ejecutor 4.1.4 recién descomprimido a "knime_executor"

  1. Después de confirmar que tanto el Servidor como el Ejecutor estaban configurados correctamente, cambiamos el archivo knime-server.config ubicado en el directorio /workflow_repository/conf/ y agregamos la siguiente línea:

com.knime.server.job.save_workflow_summary=falso

Lo que desactivó esta característica que estaba causando el problema. Lo que había estado sucediendo es que el workflow_summary tardaba demasiado en generarse después de que se ejecutaba el flujo de trabajo, lo que provocaba que el servidor se congelara.

La configuración de resumen del flujo de trabajo permite que los metadatos se escriban en un archivo xml después de que se haya ejecutado cada flujo de trabajo. Puede leer más sobre la funcionalidad de esta característica aquí: https://www.knime.com/blog/compliance-and-explainability-with-metadata-mapping

Los elementos anteriores no incluyen los cambios para usar RMI en lugar de Qpid: https://docs.knime.com/2020-07/server_update_guide/index.html#switch-to-qpid

Este problema se ha solucionado con la nueva versión.

Problema abierto actual:

El nuevo problema (27881) que Marco MKT tiene ahora con el ejecutor RMI puede ser un error de permisos. Si usa sudo es que alguien puede estar cambiando los permisos para que funcione. Asegúrese de que el usuario (Knime) tenga permiso en los archivos.

Obtenga los registros del servidor y podríamos ver lo que está sucediendo.

En un futuro cercano, puede ser bueno revertir algunos de los cambios que hizo KNIME para que pudiera ejecutarse con RMI en lugar de Qpid. Podemos llamarlo una "comprobación del estado del sistema" para aprovechar todas las funciones.

Solución:

Se elimine una serie de registros JMX en el archivo knime.ini. A la fecha el problema desapareció.

Texto de la solución:

Estamos viendo muchos "Errores de puerto en uso" para el ejecutor cuando se está iniciando. Eventualmente, comienza porque el puerto en uso está disponible. Creo que por eso los tiempos de inicio varían tanto, a veces ese puerto está disponible, otras veces no. Cuando no es así, el servidor espera y vuelve a intentarlo. Esta podría ser la raíz de por qué las nuevas empresas están tardando tanto.

El puerto es 9000, que es el puerto que configuramos para el monitoreo de JMX hace meses y se puede eliminar de manera segura. Esas configuraciones deben estar en el archivo knime.ini con el ejecutor. Se verían algo como

  • Dcom.sun.management.jmxremote

  • Dcom.sun.management.jmxremote.port=9000

  • Dcom.sun.management.jmxremote.ssl=falso

  • Dcom.sun.management.jmxremote.authenticate=false

  • Las líneas y cualquier otra con la sintaxis "jmxremote" se pueden eliminar de forma seguraarchivo knime.ini con el ejecutor. Se verían algo como

  • Dcom.sun.management.jmxremote

  • Dcom.sun.management.jmxremote.port=9000

  • Dcom.sun.management.jmxremote.ssl=falso

  • Dcom.sun.management.jmxremote.authenticate=false

  • Las líneas y cualquier otra con la sintaxis "jmxremote" se pueden eliminar de forma segurart=9000

  • Dcom.sun.management.jmxremote.ssl=falso

  • Dcom.sun.management.jmxremote.authenticate=false

Las líneas y cualquier otra con la sintaxis "jmxremote" se pueden eliminar de forma seguraersiones 4.11.4) 2021-01-13 (solucionado).

Problemas con el cambio de licencia (Dinant) 2021-04-6

Contexto:

KNIME Portal no arranca porque no reconoce el cambio de la licencia por vencimiento. Dinant hizo el cambio de la licencia a través del Web Portal pero no es reconocida y continúa apareciendo la licencia vencida.

Organizaciones afectadas:

  • Dinant

Procedimiento de solución:

  1. Se intentó nuevamente con el cliente aplicar la nueva licencia a través del Web Portal, pero sigue apareciendo un letrero que no permite ingresar porque la licencia (que aún hace referencia a la anterior) está vencida.

  2. Pedimos al cliente que ingresara a la instancia donde está instalado el KNIME Server y que ingresara a la carpeta del KNIME Executor. Allí evidenciamos que:

    • En la carpeta License del Knime_Executor aparecía la licencia nueva, entonces podíamos descartar que fuera ese el inconveniente.

    • Preguntamos por la carpeta de Knime_Workspace y esa estaba ubicada fuera del Knime_Executor actual (en una carpeta de instalación anterior.

    • En la carpeta de License del Knime_Workspace aparecían varias licencias, pero NO la actual. Procedimos a borrar las licencias y poner la actual.

    • Se re-ejecutó el server y la licencia funcionó

Solución:

Debe tenerse en cuenta que si la carpeta del Knime_Workspace NO está dentro de la carpeta del Knime_Executor, probablemente la instalación de la licencia desde el Web Portal no sea efectiva, y se deba ingresar a la instancia del KnimeServer para copiar manualmente la licencia en la carpeta del Knime_Wokspace.

Problemas con el remitente de los correos desde el servidor (Enel) 2021-04-30

Contexto:

Cuando se configuró el correo para las notificaciones del servidor, el remitente de los correos aparecían con caracteres extraños y sin un nombre real. Parecía Spam.

Organizaciones afectadas:

  • ENEL

Procedimiento de solución:

  1. Se les ayudó a hacer la configuración del correo para el servidor desde el archivo 'knime-server.config' de la carpeta 'workflow_repository/config'.

  2. Las líneas que se les dieron para adicionar en el archivo fueron:

    • mail.smtp.from=XXXX@XXXX.XXX

    • mail.smtp.port=587

    • mail.smtp.auth=true

    • mail.smtp.user=XXXX@XXXX.XXX

    • mail.password=XXXXX

    • mail.smtp.ssl.enable=false

    • mail.smtp.starttls.enable=true

Solución:

Se consultó a KNIME y nos pidieron que se cambiara en el archivo knime-server.config el parámetro 'mail.smtp.from' por 'mail.from'. Parece que ha sido un error que quedará corregido en la versión 4.12.3 del Server.

Con eso se solucionó y el remitente ya aparece de forma correcta.

Problemas con la actualización Knime server 14.3.0

Contexto:

Cuando se realiza la actualización de la versión 4.12 a la versión 4.13.0 se debe cambiar el archivo knime.ini ya que debemos definir el bróker para iniciar el ejecutor ya que sin esta linea nos aparece un error al momento de iniciar el start-executor.sh

NO ADRRESS TO THE MESSAGE BROKER DEFINED

Organizaciones afectadas:

  • IQUARTIL

Procedimiento de solución:

  1. Se debe cambiar el archivó knime.ini en la ultima linea se debe agregar:

Dcom.knime.enterprise.executor.msgq=amqp://knime:20knime16@127.0.0.1/

  1. El archivo knime.ini debe quedar de la siguiente manera

    • -startup

    • plugins/org.eclipse.equinox.launcher_1.6.100.v20201223-0822.jar

    • --launcher.library

    • plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.100.v20210209-1541

    • -vm plugins/org.knime.binary.jre.linux.x86_64_11.0.10.20210416/jre/bin

    • -vmargs

    • -server

    • -Dsun.java2d.d3d=false

    • -Dosgi.classloader.lock=classname

    • -XX:+UnlockDiagnosticVMOptions

    • -XX:+UseG1GC

    • -Dsun.net.client.defaultReadTimeout=0

    • -XX:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot

    • -Xmx6G

    • -Dorg.eclipse.swt.internal.gtk.disablePrinting

    • -Darrow.enable_unsafe_memory_access=true

    • -Darrow.memory.debug.allocator=false

    • -Darrow.enable_null_check_for_get=false

-Dcom.knime.enterprise.executor.msgq=amqp://knime:20knime16@localhost/

Solución:

Se consultó la documentación de KNIME y se agrego el parámetro por

-Dcom.knime.enterprise.executor.msgq=amqp://knime:20knime16@localhost/

Con eso se solucionó y se ejecuta el start-executor.sh