Motivación

Este documento ha sido creado para ayudar a soporte, consultores y desarrolladores que se hagan cargo de JmxServer ante un error en el producto.

Para soporte, este documento ayudará a localizar si el fallo puede ser de nuestro producto, o de la configuración del sistema monitorizado. En el caso de desarrolladores, no voy a poder anticipar qué va a fallar, pero puede ser una guía interesante para conocer el producto internamente.

Desde la salida del hotfix HF08 para ThinkServer, no ha hecho falta volver a modificar el producto ante los problemas que han surgido posteriormente, todas estas incidencias se solucionaron reconfigurando el cliente.

Este documento no va a dar por supuesto que se siguieron correctamente los pasos de configuración del manual de instalación, ya que no pocas veces el error se sitúa en esta fase.

Consejo: Debería ser revisado por personal que no trabajara en la instalación inicial y con todo el espíritu crítico posible. Solo así se ven todos los errores. Esto siempre se ha aplicado a los desarrolladores también.

El objetivo final es que los problemas no solo sean correctamente notificados a I+D, sino que puedan ser atajados desde soporte al tener el conocimiento especifico adecuado.

 

Versiones soportadas

Es importante como paso previo comprobar que la versión del servidor de aplicaciones en cuestión esté soportada por nuestros ThinAgents. Nosotros necesitamos la Java Virtual Machina 1.5 como prerrequisito, lo que hace que no soportemos versiones viejas de los diferentes servidores de aplicaciones. Las versiones soportadas actualizadas están en el documento “Supported Operating Systems and Applications” disponible en la Intranet y desde la documentación de referencia de la VMC SmartConsole.

 

Errores comunes

Los problemas en nuestro producto o en el servidor se manifestaran de maneras distintas:

- Flechita azul no esperada. - Error while connecting to JMX Service: SOAP_TCP_ERROR. - Error while retrieving information from system. Check system configuration settings and verify network accessibility - Script error. - Valores sin sentido. - Basura en los logs.

Estos síntomas nos dicen mucha información, y la forma de afrontar este problema es muy distinta de unos a otros.

 

Flechita azul no esperada

Casi siempre va a significar que el thinAgent se conecta sin problemas con JmxServer, que se conecta correctamente con el servidor de aplicaciones, pero no recupera la información solicitada. Falta alguna de las variables que necesita para calcular la salud actual.

Los scripts no han sido preparados para especificar qué variable es la que falta, siempre se puede modificar dicho script python para que lo muestre para el monitor en concreto.

It not VarDefined("FreeMemoryCount"): SendMessageToConfigurator( ERROR, “FreeMemoryCount not defined” )

Pero esto no es sino una verificación de lo que ya sabíamos que estaba pasando, y la forma de solucionarlo varía según el sistema.

WebSphere:

Necesitaremos un dato más para conocer la naturaleza exacta del problema, y es conocer el tipo de búsqueda que hace sobre los MBeans. ¿Busca el MBean concreto para pedirle las estadísticas? ¿O acaso busca sobre PerfMBean, el famoso MBean proxy de WebSphere?

Sabremos si es de un tipo o de otro mirando la petición en xml que se almacena en el dataSource afectado. Pondremos un ejemplo de cada uno:

 

Mbean concreto:

<ImplementationDataSource> <JMXAgenteDS_Attributes> <JMXAgent_Source server="192.168.1.10" port="8880" id="1" user="" password="" protocolo="" servicio="" HostProvider="localhost" PortProvider="8080" KeyStore="" KeyStorePass="" TrustStore="" TrustStorePass=""> </JMXAgent_Source> <attribut nom="stats" alias="stats" tipus="javax.management.j2ee.statistics.Stats" valor="" instancia="WebSphere:name=JVM,process=*,platform=*,node=*,j2eeType=JVM,J2EEServer=*,version=*,type=JVM,mbeanIdentifier=JVM,cell=*,spec=*" descri=""> </attribut> </JMXAgenteDS_Attributes> </ImplementationDataSource>

Esta implementación, extraida del monitor “JVM Free Memory Monitor”, nos indica que solicita el atributo (attribut) stats, de una instancia concreta "WebSphere:name=JVM,process=*,platform=*,node=*,j2eeType=JVM,J2EEServer=*,version=*,type=JVM,mbeanIdentifier=JVM,cell=*,spec=*". Es por tanto del tipo Mbean concreto.


PerfMBean:

<ImplementationDataSource> <JMXAgenteDS_Attributes> <JMXAgent_Source server="127.0.0.1" port="8880" id="1" user="" password="" protocolo="" servicio="" HostProvider="127.0.0.1" PortProvider="8080" KeyStore="" KeyStorePass="" TrustStore="" TrustStorePass=""> </JMXAgent_Source> <operation nom="getStatsArray" alias="getStatsArray" tipus="[Lcom.ibm.websphere.pmi.stat.WSStats;" descri="" instancia="WebSphere:name=PerfMBean,process=*,platform=*,node=*,version=*,type=Perf,mbeanIdentifier=PerfMBean,cell=*,spec=*"> <parameterList> <parameter tipus="[Lcom.ibm.websphere.pmi.stat.StatDescriptor;" valor="Servicio SIB"> </parameter> <parameter tipus="java.lang.Boolean" valor="true"> </parameter> </parameterList> </operation> </JMXAgenteDS_Attributes> </ImplementationDataSource>

Lo más importante para distinguirlos no es que uno sea un atributo y otro una operación, ya que también se puede ( y se hace ) invocar operaciones sobre MBeans concretos, tampoco que la operación sea getStatsArray ( aunque ya nos da una buena pista ), sino el MBean invocado, es de tipo Perf y se llama PerfMBean. El parámetro de tipo StatDescriptor hace referencia a una ruta en un arbol.

Este tipo de MBeans funciona de manera distinta, y los problema que manifiesta son tambien distintos.


MBean concreto, flechita azul:

O el MBean no existe, o no está publicando la información que solicitas.

Podemos hacer uso de JmxBrowser ( integrado en los DataSource de la mayoria, sino todos, los monitores que funcionan con MBean concreto. Y localizar con mucho trabajo si el mbean está o no.

De tener mucha experiencia, podría localizar un problema con el listado de propiedades de MBean y corregirlo.

Pero este no es quizá el enfoque correcto, mejor:

Vaya a la consola de configuración de WebSphere, y asegurese de que ha activado la publicación de todas las estadísticas. Si lo hace en la pestaña RunTime no debería necesitar reiniciar.

Cuando vea que funciona perfectamente, una vez terminado el trabajo de implantación, limite la publicación con la ayuda del documento “Guia de estadisticas para activar monitores.doc”.


PerfMBean, flechita azul:

Vaya a la consola de configuración de WebSphere, y asegurese de que ha activado la publicación de todas las estadísticas. Si lo hace en la pestaña RunTime no debería necesitar reiniciar.

Cuando vea que funciona perfectamente, una vez terminado el trabajo de implantación, limite la publicación con la ayuda del documento “Guia de estadisticas para activar monitores.doc”.

Solo hay documentado un error que se escape a lo anteriormente comentado, y es que de forma excepcional, la rama “SIB Service” se encuentra traducida a varios idiomas, sin ningún tipo de atajo internacional. Esto supone que en la versión inglesa deberíamos cambiar el Xml del DataSource ( en la rama maestra o en la instanciación de la carpeta config ) el atributo “valor” por SIB Service (inglés), “Service SIB” (francés), “Servicio SIB” (español)…

Esto solo ocurre con la rama SIB Service. El nombre adecuado que habría que poner es el que se encuentra en la consola de WebSphere, sección Tivoli Performance Viewer.

 

Otros servidores:

Los demás servidores no tienen una granularidad tan alta en la publicación de variables, no se han documentado este tipo de problemas en Tomcat, JBoss o WebLogic.

En cualquier caso, contamos con una poderosa herramienta para comprobar hasta que punto está el servidor de nuestro cliente bien configurado. JConsole puede consultar los MBean e invocar las mismas operaciones que JMXServer ( de hecho alguna más ).

No dudéis en usarla, se encuentra en los JDK 1.5 y 1.6.

 

Error while connecting to JMX Service: SOAP_TCP_ERROR

La causa del problema está muy clara con este mensaje: JMX Server, nuestro producto, o no ha arrancado o está inaccesible.

Consultar services.msc, ¿Está arrancado? Si lo está, consultar el firewall, el servicio de windows debe estar activo y el propio firewall deshabilitado o permitiendo nuestra aplicación.

Si no está arrancado, lo normal es que haya habido una colisión de puertos, mirar el log.

Launching a JVM... DEBUG | 2008/06/07 12:30:05 | com.tango.jmx.was.server.Main[main - line -1]: Log activado ERROR | 2008/06/07 12:30:06 | com.tango.jmx.was.server.Main[main - line -1]: Puerto ocupado, seleccione otro puerto en los archivos de configuracion: java.net.BindException: Address already in use: JVM_Bind;[java.net.PlainSocketImpl.bind(Unknown Source)] INFO | jvm 4 | 2008/06/07 12:30:06 | java.net.BindException: Address already in use: JVM_Bind INFO | jvm 4 | 2008/06/07 12:30:06 | at java.net.PlainSocketImpl.socketBind(Native Method) INFO | jvm 4 | 2008/06/07 12:30:06 | at java.net.PlainSocketImpl.bind(Unknown Source) INFO | jvm 4 | 2008/06/07 12:30:06 | at java.net.ServerSocket.bind(Unknown Source) INFO | jvm 4 | 2008/06/07 12:30:06 | at java.net.ServerSocket.<init>(Unknown Source) INFO | jvm 4 | 2008/06/07 12:30:06 | at java.net.ServerSocket.<init>(Unknown Source) INFO | jvm 4 | 2008/06/07 12:30:06 | at com.tango.jmx.was.server.Main.<init>(Unknown Source) INFO | jvm 4 | 2008/06/07 12:30:06 | at com.tango.jmx.was.server.Main.main(Unknown Source) ERROR | wrapper | 2008/06/07 12:30:06 | JVM exited while loading the application.

La forma de cambiar esto, fichero JMXServer\conf\configWAS.conf, propiedad com.tango.jmx.was.server.port para WAS o com.tango.jmx.jsr.server.port para JSR.

No hay colisión de puertos, estamos usando WebSphere con seguridad, hemos instalado el cliente java de IBM, comprobamos que está instalado, comprobamos las rutas y deben corresponderse con las de JMXServer\conf\wrapperWAS.conf Especialmente si el servicio no arranca y vemos mensajes tan raros como este:

STATUS | wrapper | 2008/06/07 13:33:24 | --> Wrapper Started as Service STATUS | wrapper | 2008/06/07 13:33:24 | Launching a JVM... INFO | jvm 1 | 2008/06/07 13:33:24 | No se encuentra la clase Java: de ERROR | wrapper | 2008/06/07 13:33:24 | JVM exited while loading the application.

Esto da lugar por tener así la configuración:

  1. Java Application

wrapper.java.command=C:\Archivos de programa\IBM\WebSphere\AppClient/java\bin\java

wrapper.java.additional.1="-Dcom.ibm.SSL.ConfigURL=file:C:\Archivos de programa\ IBM\WebSphere\AppClient/properties/ssl.client.props" wrapper.java.additional.2="-Dcom.ibm.SOAP.ConfigURL=file:C:\Archivos de programa\ IBM\WebSphere\AppClient/properties/soap.client.props"

Aseguraos de que las propiedades wrapper.java.additional.* estan escritas en una sola linea, y que las rutas son correctas.

 

Error while retrieving information from system. Check system configuration settings and verify network accessibility

Este error, mayoritario, es un infierno, por la cantidad de posibles orígenes que puede tener. Lo único que sabemos es que JmxServer no encuentra, o algo va muy mal, con el servidor de aplicaciones de turno.

1- Asegurarse de que WebSphere/JBoss/Tomcat/WebLogic está arrancado, y en la IP donde dice estar. Revisar bien la configuración de puertos. En el manual de cada ThinAgent se especifica cómo configurar bien la aplicación. Aquí hay que pelearse un poco con la consola de administración de cada servidor. 2- Asegurarse de que el canal de comunicaciones está abierto, es decir, desde la máquina JmxServer, debe funcionar un ping y un telnet a WebSphere. Desde línea de mandato (CMD) hacemos (en el caso de WAS), TELNET NOMBRESERVIDOR 8880. Si va bien la pantalla se queda en blanco, o salen unos símbolos raros. En cambio esto sería un error.

3- También podemos mirar de acceder vía browser. Hay que tener en cuenta que si la seguridad está activada también tenemos que mirar https y no solo http. Si falla da un error 404, si puede acceder nos devuelve un XML con cierta info.

 

4- Mirar log. A partir de entonces, todo lo que necesitaremos será mirar el log y ver qué pistas nos da. TSJMXServerWAS.log o TSJMXServerJSR.log

Fallo de autenticación

Si en el log encontramos entradas como ésta:

INFO | 2008/06/10 09:16:48 | server.Service[<init> - line -1]: Servicio activo DEBUG | 2008/06/10 09:16:48 | server.Service[getData - line -1]: Recibida petición desde axis DEBUG | 2008/06/10 09:16:48 | server.Service[getData - line -1]: XML Peticion: <?xml version="1.0" encoding="UTF-8"?> <request server="localhost" port="8880" id="1" user="admin2" password="6127C7F7DF" protocolo = "" servicio = "" HostProvider= "localhost" PortProvider= "8080" KeyStore = "" KeyStorePass = "" TrustStore = "" TrustStorePass = ""> <attribut nom = "stats" alias = "stats" tipus = "javax.management.j2ee.statistics.Stats" valor= "" instancia = "WebSphere:name=JVM,process=*,platform=*,node=*,j2eeType=JVM,J2EEServer=*,version=*,type=JVM,mbeanIdentifier=JVM,cell=*,spec=*" descri = ""></attribut></request> DEBUG | 2008/06/10 09:16:48 | server.ServiceManager[o00000 - line -1]: Iniciando peticion de datos a localhost:8880 ERROR | 2008/06/10 09:16:48 | server.ServiceManager[o00000 - line -1]: Error en la autenticacion ERROR | 2008/06/10 09:16:48 | server.ServiceManager[getData - line -1]: Error connecting to the agent. DEBUG | 2008/06/10 09:16:48 | server.Service[getData - line -1]: XML Respuesta: <?xml version="1.0" encoding="ISO-8859-1"?> <Error Cause="Error connecting to the Agent" />

Puede deberse a tres causas directas:

- Usuario o password incorrectos o No hay mucho que explicar aquí. - El usuario no tiene permisos de monitor o Revisar la referencia del producto y constatar de que el usuario es administrador o bien supervisor - Este conjunto ip/puerto/servicio ya ha sido usado con otro usuario y password o Internamente, al reutilizar conexiones, no se puede comprobar el usuario y password contra el servidor para cada petición, por lo que se comprueba dentro de JmxServer y debe coincidir con el usuario que realizó la primera conexión con ese servidor en concreto. Es decir, si se crean los datasources con el administrador, no se puede simplemente cambiar después el usuario y usar el usuario “monitor” (con menos permisos). o Para solucionar este punto, reinicie JmxServer.

 

Mala configuración del servidor ajeno

Todos los servidores son proclives a no publicar las estadísticas de configuración, se suele solucionar siendo fiel al manual de configuración.

El síntoma principal en el log es:

INFO | 2008/07/02 15:48:48 | starting up SimpleAxisServer on port 8081 (C:\Program Files\Tango04\ThinkServer\JMXServer) INFO | 2008/07/02 15:49:18 | server.Service[<init> - line -1]: Servicio activo INFO | 2008/07/02 15:49:18 | server.Service[getSystem - line -1]: Rescatando la estructura de MBeans de 10.162.38.8 ERROR | 2008/07/02 15:49:21 | com.tango.jmx.new.oOoO[<init> - line -1]: Error getting connection because of IOException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect ERROR | 2008/07/02 15:49:21 | com.tango.jmx.server.C[<init> - line -1]: Error desconocido al crear la conexión: com.tango.jmx.server.F: JMXAgentConnectionFactory[createJMXAgentConnection(JMXSource jmxTargetSource)]: Exception :JMXAgentConnectionJSR[JMXAgentConnectionJSR]: Error getting connection because of IOException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect;[com.tango.jmx.server.C.<init>(Unknown Source)] ERROR | 2008/07/02 15:49:21 | com.tango.jmx.server.E[Ò00000 - line -1]: Error añadiendo la fuente Server: 10.162.38.8 Port: 9005 Service: jmxrmi Protocol: rmi a la cache: com.tango.jmx.server.F: Error connection: null;[com.tango.jmx.server.E.Ò00000(Unknown Source)] ERROR | 2008/07/02 15:49:21 | com.tango.jmx.server.E[class - line -1]: Error añadiendo fuente a la cache: com.tango.jmx.server.F: JMXServer[addSourceToStructure(JMXSource sourceTarget)]: Error adding source to cache: Error connection: null;[com.tango.jmx.server.E.class(Unknown Source)] INFO | 2008/07/02 15:49:21 | com.tango.jmx.server.F: JMXAgentConnectionFactory[createJMXAgentConnection(JMXSource jmxTargetSource)]: INFO | 2008/07/02 15:49:21 | Exception :JMXAgentConnectionJSR[JMXAgentConnectionJSR]: INFO | 2008/07/02 15:49:21 | Error getting connection because of IOException: Connection refused to host: 127.0.0.1; nested exception is: INFO | 2008/07/02 15:49:21 | java.net.ConnectException: Connection refused: connect


Algunos ejemplos documentados:

JBoss

A pesar de estar configurado para publicar las estadísticas, solo publicaba desde línea de comandos, no desde la ejecución como servicio. Por otro lado, una vez solucionado esto, encontramos que solo las publicaba para la interfaz localhost.

Para averiguar que pasó, como siempre, contamos con JConsole. Si no somos capaces de recuperar la lista de MBeans ( para JBoss, Tomcat o WebLogic ), tendremos que focalizar nuestro esfuerzo en la configuración del servidor de nuestro cliente, y no tanto en nuestro producto.

La solución en el banco Itau se redujo por ejemplo a

_____________ Correo electrónico ________________

el establecimiento de variables debe ser toda en la misma linea, quiero decir:

set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dcom.sun.management.jmxremote.port=9005 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl -Djboss.platform.mbeanserver

en lugar de

set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dcom.sun.management.jmxremote.port=9005 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl -Djboss.platform.mbeanserver

________________________________________________

Otro correo del mismo caso.

________________ Correo electrónico ________________


1- Me instalé JBoss en el ordenador Host (por darle un nombre), y lo configuré para que sacara JMX por el puerto 9005 (como en el banco ITAU).

2- Desde el ordenador Guest (por darle otro nombre distinto) no funcionaba JMXServer.

3- Desde el mismo ordenador Host, sí funcionaba JConsole.

Hasta este punto, estamos exactamente igual que en el banco Itau.

4- Desde Guest, no funciona JConsole

Atención chicos, esto no lo pudimos hacer en Itau porque no tenian la JDK instalada en el ordenador donde teniamos JMXServer.

A partir de este momento, el problema pasa a ser de nuevo un problema de conectividad de JBoss.

Sintomas:

  • ping Guest -> Host OK
  • telnet Guest -> Host OK, el puerto se abría.

PERO ni JConsole ni JmxServer de Guest funcionan.

Despues de mucho darle vueltas, he encontrado una opción de run.bat (de jboss) "run.bat -b 0.0.0.0" va a hacer "binding" de jboss en todas las interfaces. Como si por defecto solo sacara JMX por localhost.

también me ha funcionado ( preferible por seguridad ): run.bat -b 192.168.0.83 (la ip de Host, donde está JBoss). run.bat -b anavarro (autentico nombre de Host en la red ).

no ha funcionado: run.bat -b 192.168.0.0 (el segmento de red comun)

      • aquí he descubierto algo: mensaje en la excepción de JMXServer: Connection refused to host: 192.168.0.0; ***
      • obviamente no me he intentado conectar a 192.168.0.0, sino a 192.168.0.83.
      • es decir, 192.168.0.0 es una información que devuelve el servidor.
      • Encadeno otra reflexión, si el error que teníamos era Connection refused to host: 127.0.0.1;
      • Puedo afirmar y afirmo que esta haciendo binding con 127.0.0.1
      • y por tanto JMX solo está siendo accesible desde localhost, que es lo unico que pudimos hacer por webex el otro dia.

Me gustaría, si fuera posible, que pudierais comprobar esto antes de continuar buscando la solución definitiva. Se trata nada mas de parar el servicio JBoss, ejecutarlo por linea de comandos con run.bat -b 0.0.0.0 o las otras opciones.

Si el cliente no quiere dejar 0.0.0.0, siempre podreis poner su nombre en la red, por si su ip no fuera estatica.

________________________________________________

Estos eran ejemplos de mala configuración sobre el servidor JBoss. No tengo información para poner más ejemplos, pero creo que son bastante gráficos. No hay bala de plata para esto sino mirar manual y comprobar todo, al ser posible paso a paso.

Mala configuración del servidor JmxServer

También puede pasar esto, si. Principalmente:

Revisar Ip y puerto, que apunten correctamente al servidor deseado. Ya hemos analizado el mensaje si el usuario o password no son correctos.

Si es WebLogic, tenemos que usar una JDK 1.5, ya que existen incompatibilidades de serialización entre JDK 1.6 y 1.5. (Esta última es la que usa WebLogic).

Si es WebSphere, y usa seguridad, hay que instalar el cliente IBM y adaptar las directivas de seguridad del fichero de configuración como dice el manual, sino podríamos encontrarnos con un mensaje de este tipo.

DEBUG | 2008/06/10 12:00:55 | server.ServiceManager[getData - line -1]: Iniciando peticion de datos a localhost:8880 DEBUG | 2008/06/10 12:00:55 | server.ServiceManager[getData - line -1]: La fuente localhost:8880 no esta en la caché. DEBUG | 2008/06/10 12:00:55 | com.tango.jmx.B.return[<init> - line -1]: Current classpath: ./lib/wrapper.jar;./serverWAS.jar ERROR | 2008/06/10 12:00:55 | com.tango.jmx.B.return[<init> - line -1]: Error creando WASDriver: com.ibm.websphere.management.exception.ConnectorException: ADMC0016E: El sistema no puede crear un conector SOAP para conectar un host localhost en el puerto 8880;[com.tango.jmx.D.new.<init>(Unknown Source)] ERROR | 2008/06/10 12:00:55 | com.tango.jmx.B.o0OO[o00000 - line -1]: Timeout conectando a Server: localhost Port: 8880 Service: Protocol: : com.tango.jmx.D.OOoO: ADMC0016E: El sistema no puede crear un conector SOAP para conectar un host localhost en el puerto 8880;[com.tango.jmx.B.return.<init>(Unknown Source)] INFO | jvm 1 | 2008/06/10 12:00:55 | 10-jun-2008 12:00:55 com.ibm.ws.ssl.provider.AbstractJSSEProvider INFO | jvm 1 | 2008/06/10 12:00:55 | GRAVE: CWPKI0029E: El proveedor de contexto SSL "IBMJSSE2" no es válido. Este proveedor se especifica en el alias de configuración SSL "DefaultSSLSettings" cargado del archivo de configuración SSL "file:C:\Archivos de programa\IBM\WebSphere\AppClient/properties/ssl.client.props". El mensaje de error ampliado es: "no such provider: IBMJSSE2". INFO | jvm 1 | 2008/06/10 12:00:55 | 10-jun-2008 12:00:55 com.ibm.ws.ssl.provider.AbstractJSSEProvider INFO | jvm 1 | 2008/06/10 12:00:55 | GRAVE: CWPKI0029E: El proveedor de contexto SSL "IBMJSSE2" no es válido. Este proveedor se especifica en el alias de configuración SSL "DefaultSSLSettings" cargado del archivo de configuración SSL "file:C:\Archivos de programa\IBM\WebSphere\AppClient/properties/ssl.client.props". El mensaje de error ampliado es: "no such provider: IBMJSSE2". INFO | jvm 1 | 2008/06/10 12:00:55 | com.ibm.websphere.management.exception.ConnectorException: ADMC0016E: El sistema no puede crear un conector SOAP para conectar un host localhost en el puerto 8880 INFO | jvm 1 | 2008/06/10 12:00:55 | at com.ibm.websphere.management.AdminClientFactory.createAdminClient(AdminClientFactory.java:479)


Este error ha sucedido cuando se ha cambiado la JVM de IBM por la de Sun cuando WebSphere usa seguridad.

 

Dudas de si el error es de nuestro producto o de configuración del sistema – Usar un browser JMX

Lo mejor es usar un browser JMX para conectarnos al servidor de aplicaciones y ver si tiene los mismos problemas que nosotros. Hay muchos, y sabiendo que WAS va a aparte del resto, el mejor es Sentry JMX Browser. \\development\Software\WebSphere\JMXBrowsers\RECOMENDADO SentryJMXBrowser_Install_1000.exe Estuve probando el de MC4J y tiene un problemilla con WAS. La versión 2 alpha no está probada con WAS6.1, además necesita que en la máquina local esté instalada la misma versión del servidor de aplicaciones al que quieres acceder. La versión 1.2 sólo soporta hasta WAS 6.0, y tiene los mismos problemas. Sólo hay que tener en cuenta que principle/credential son user/password

Mensaje que da cuando el servidor está caído, hay problemas de autenticación o (posiblemente) cuando hay conflicto de puertos o está cerrado.

Si puede conectar recupera una lista con los nodos y celdas del servidor.

Script error.

Pues eso, si veis alguno, notificadlo y será cambiado J

 

Basura en los logs

Éste es un problema exclusivo de WebSphere, y tiene dos formas de solucionarse, la buena (corrigiendo codigo y servidor ) y la mala ( diciendo al servidor que aumente el umbral de mensaje hasta Severe, filtrando los mensajes Warning y desapareciendo del Log).

Se ha hecho un gran esfuerzo en limpiar el codigo de JmxServer y que no use nada de la API abandonada, que se encuentra muy mezclada con la recomendada por IBM.

Nos encontramos con distintos mensajes tanto en nuestro log como en el de SystemOut.log ( log de WebSphere) , los trataremos por separado.


[2/22/08 9:25:43:570 CET] 0000002c SystemOut O WARNING: wrong data type: must be CountStatisticImpl

De este mensaje parece que no somos responsables. Nuestro compañero Thibaud D. desde Servicios Profesionales encontró un parche disponible para eliminar este mensaje.

Descripción y descarga: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg1PK62196


[2/20/08 3:49:21:688 CET] 00000080 AdminServiceI W ADMN0037W: The Perf operation "getConfigs" is deprecated. As of 6,0, this method is deprecated.

Este mensaje ya no existe con ThinkServer 1.6.1.10 + HF08.

El proyecto fue revisado con la ayuda de IBM y se eliminó la API mal utilizada.


[2/20/08 16:54:36:592 CET] 0000002e PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=172.24.8.124,time=1203070374858,pid=7844,reqid=8192,event=1 - current:ver=1,ip=172.24.8.124,time=1203070374858,pid=7844,reqid=8195,event=1 type=JDBC detail=executeUpdate elapsed=214

Este mensaje procede de "Request Metrics" Request Metrics es un mecanismo de autoevaluación de respuesta de WebSphere, independiente de PMI o JMX que es lo que usamos para monitorizar.

WAS puede evaluar todos o algunos de sus componentes, y estos mensajes pueden ser redirigidos a un archivo de log o a un programa de tratamiento de datos personalizado.

En este caso, SOCRAM lo tiene activado, y la salida por defecto es redirigido a SystemOut.log, si no van a utilizarlo, pueden desactivarlo donde es mostrado en la captura de pantalla adjunta.

Si lo necesitan, se recomienda cambiar la salida, puesto que no les gusta tenerlo en el log SystemOut.

En cualquier caso, no es necesario ni afecta a nuestra monitorización.

 

 

Valores sin sentido en los monitores

Esto solo lo he visto una vez, y nunca me lo han notificado. En WebSphere, los uptime desbordan al mes aproximadamente de estar usándolos, apareciendo valores negativos. Si se observa el sistema con Tivoli, ocurre lo mismo. Es un fallo de WebSphere. Por lo general todo lo que se enmarque en este apartado se deberá al servidor, ya que nosotros no tratamos los datos.

JMX Explorer no conecta en Windows Server 2003

De un mail de Alberto…

Nos habiamos encontrado en varios clientes que la aplicación JMX Explorer, que se usa para seleccionar los MBeans en algunos monitores de JMX (WebSphere, JBoss, Tomcat o WebLogic) no funcionaba, ya que no conseguía conectar con JMX Server para descargar dicha lista y representarla como árbol. En común en los clientes descubrimos que ThinkServerConfigurator se ejecutaba sobre Windows Server 2003.

Este bug tiene su origen en Delphi y carece de parche, sin embargo tiene un workaround, y es desactivando la prevencion de ejecución de datos (DEP).

(W2003) MI PC (propiedades) -> Opciones Avanzadas -> Rendimiento -> Prevención de ejecución de datos y en inglés My Computer (properties) -> Advanced options -> Performance -> Data execution prevention

En este menú hay que añadir el ejecutable ThinkServerConfigurator.exe a la lista de archivos para los que no hay que aplicar DEP. Después será necesario reiniciar el sistema operativo.

Esta solución ha funcionado para WindowsServer 2003, que por ahora era el unico caso en el que no funcionaba y no siempre, ruego feedback si esto funciona o no en clientes.

 

Ayudanos a ayudarte

Si como consultor o soporte, después de seguir los distintos manuales, no has podido resolver el problema, estos son los pasos adecuados para que podamos ayudarte.

1- Detén JmxServer 2- Aumenta el nivel de log hasta FINEST en el archivo de configuración (log4j.logger.com.tango.jmx.server.level en configWAS.conf o configJSR.conf). 3- Elimina o back-up los archivos de log de la carpeta log. Lo que queremos es tener el log lo mas acotado y detallado posible. 4- Reproduce el problema 5- Envianos el/los nuevo/s archivo/s de log, la configuración del monitor que ha provocado el error, un resumen de la topología ( ips y puertos ) de la red. Además: a. Para WebSphere, añadir el log del servidor se encuentra en “C:\{Program Files}\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\{Server name}\” y se llaman SystemOut.log y SystemErr.log. b. Para Weblogic, buscar wl_server.log, localización no muy definida. c. Para JBoss, en C:\jboss-4.2.2.GA\server\default\log, y serán boot.log y server.log d. Para Tomcat, añadir el log del servidor, que se encuentra en C:\ :\{Program Files}\Apache Software Foundation\Tomcat 6.0\logs y comienza por jakarta_service_.


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: October 24, 2018