World Map
Java Service Wrapper is the easiest way to make your product more reliable.
  • Free Trial
  • Buy Now
Solución de problemas

Solución de problemas: Problemas

Solución de Problemas: Soluciones

Mi programa no está corriendo tan rápido como yo esperaba.

En general, una aplicación monitoreada con el Wrapper debe ejecutarse tan rápido como lo hace cuando se ejecuta independiente. A continuación le damos algunos lugares para empezar a buscar.

Salida de Datos de la Consola

En algunas plataformas, incluyendo Windows, el envío de grandes cantidades de texto a System.out hará que el programa reduzca su velocidad. Esto es porque toda la salida de datos está siendo enviada a la pantalla en un entorno gráfico GUI. Esto es en realidad el sistema operativo que esta consumiendo el CPU en lugar del Wrapper o su aplicación, pero el resultado final es el mismo.

Para reducir significativamente este efecto, utilice una herramienta de registro de datos el cual generará la salida a un archivo en lugar de stdout. De este modo, la salida de datos no se envía nunca al Wrapper o a la consola del usuario dando como resultado la reducción de dicha carga.

Otra opción que es igual de afectiva es configurar el nivel de registro de datos del Wrapper, usando la propiedad wrapper.console.loglevel, de modo que la salida de datos sólo se envíe al archivo de registros del Wrapper. La salida de datos de la consola está desactivada por defecto cuando se ejecuta como un servicio de Windows y la consola no ha sido activada.

Memoria

Asegúrese de que su sistema tiene suficiente memoria física para que la máquina JVM pueda ser ejecutada sin hacer ningún cambio de disco (memoria virtual en el disco duro). Debido a la forma en que Java maneja la memoria, la velocidad que se llegue a generar será normal simplemente porque Java se ve obligado de almacenar y recuperar datos en grandes cantidades de su memoria, al tratar de realizar una "recolección de basura".

Documentación Java

Otro buen lugar para buscar es en el sitio web de Oracle "Java SE HotSpot at a Glance". También recomendamos visite este enlace sobre JDC Tech Tips talking about "Garbage Collection".

Recibo un error acerca de no ser capaz de escribir un archivo pid al iniciar el Wrapper.

A partir de la versión Wrapper 3.0.5, la propiedad wrapper.pidfile fue implementada en la plataforma de Windows. Las versiones anteriores del Wrapper ignoran esta propiedad cuando se ejecuta en Windows. Sin embargo, si el archivo wrapper.conf que este usando fue creado usando alguna versión del Wrapper anterior a 3.0.0, entonces es posible que tenga que definir como "retención de datos" desde el momento en que copió el ejemplo del archivo wrapper.conf. Esto dará lugar a un error como el siguiente:

ERROR: Could not write pid file /var/run/testwrapper.pid: The
system cannot find the path specified. (0x3)

Para resolver esto simplemente edite su archivo wrapper.conf y remueva la propiedad wrapper.pidfile.

Estoy recibiendo una advertencia de que el Wrapper no puede cargar su librería nativa.

Algunos usuarios han preguntado sobre el siguiente mensaje que aparece en su archivo wrapper.log:

WARNING - Unable to load native library 'wrapper' for class WrapperManager.
          Señales del sistema no podrán ser controladas correctamente.
Este mensaje se muestra porque el componente Java del Wrapper no pudo cargar sus librerías nativas durante la inicialización. Si visita su archivo wrapper.conf podrá ver la propiedad, wrapper.java.library.path. Esta propiedad se utiliza para especificar el directorio en el que el Wrapper encontrará su librería nativa (Windows: wrapper.dll, Linux/UNIX: libwrapper.so). Usted debe colocar el archivo de la librería en el directorio especificado o cambiar la propiedad para especificar el directorio en donde se encuentra la librería.

A partir de la versión Wrapper 2.2.9, este mensaje de error se ha mejorado. Usted verá algo como lo que a continuación se presenta (Esto puede variar de acuerdo a la plataforma que este usando):

AVISO - No se puede cargar la librería nativa del Wrapper porque
          el archivo 'wrapper.dll' no se pudo localizar en la siguiente propiedad
          java.library.path:
            C:\SourceForge\wrapper\bin\..\lib
          Por favor ver la documentación para la configuración de la propiedad
          wrapper.java.library.path.
          Señales del sistema no podrán ser controladas correctamente.

No puedo instalar mi aplicación como un servicio en Windows 2000 o NT.

En Windows 2000 or NT, verá el siguiente mensaje de error si intenta instalar un servicio cuando se conecte como un usuario sin privilegios de administrador.

OpenSCManager failed - access denied.

Para solucionar esto, póngase en contacto con el administrador de su sistema y pida que le instalen el servicio, si usted es el administrador sera muy fácil de hacerlo.

Mi aplicación no inicia. ¿Qué puedo hacer para reducir el problema?

La salida de datos se encarga de la descripción del problema el cual se debe mostrar en la consola, así como la configuración del archivo de registro de valores. Para una salida de datos más detallada, edite su archivo wrapper.conf y habilite la depuración esto sucederá al desabilitar la propiedad wrapper.debug. Al hacer esto se mostrará una salida de datos más detallada de cada paso en el proceso de ejecución y monitorear su aplicación.

Si la aplicación funciona cuando no utiliza el Wrapper, pero falla con el Wrapper, entonces es muy probable que exista un problema en la forma en la que configuró el archivo wrapper.conf. Por favor revise cuidadosamente el comando utilizado para iniciar Java y analizando la salida de datos generada al ejecutar el proceso de depuración, es posible que haya un error en Classpath.

No estoy recibiendo salida de datos en el archivo de registro configurado.

Es posible que el Wrapper no sea capaz de localizar el archivo de configuración del Wrapper especificado o que por alguna razón no sea capaz de abrir el archivo de registro de datos configurado. En cualquier caso, el Wrapper registrará la salida de datos a un archivo llamado wrapper.log en el directorio de trabajo actual. Lo más probable es que el directorio de trabajo actual sea el directorio que contiene el Wrapper binario. Sin embargo, en algunos casos cuando se ejecuta como un Servicio de Windows, el archivo wrapper.log puede ser colocado en el directorio del sistema (WinNT\System32).

Mi aplicación deja de funcionar mientras se está apagando.

Al invocar System.exit() en su aplicación, el Wrapper lo detectará y tratará de apagar la aplicación limpiamente. Si durante el proceso de apagado, la aplicación invoca una vez más System.exit(), dicha invocación se bloqueará indefinidamente causando que su aplicación se congele. También surgirán problemas al invocar al método destroy() en un (AWT frame) o ventana desde el interior de un Shutdown Hook en secuencia. Para obtener más información sobre cómo evitar este problema por favor, eche un vistazo a la propiedad wrapper.disable_shutdown_hook en Descripción de Configuraciones.

Mi máquina JVM 1.2.x se congela cuando ejecuto mi aplicación con el Wrapper.

Visite el siguiente enlace para una lista de JVMs (Java Virtual Machines) compatibles con el Wrapper. A partir de la versión del Java Service Wrapper 3.4.x en adelante ya no es compatible con la versión JVM 1.2.x.

La mayoría de las características del Wrapper antes de la versión 3.4.x funcionará con la versión de JVMs 1.2.x. Sin embargo, la versión de lanzamiento del Wrapper está construida usando una versión de Java 1.4.x. La versión 1.2.x de la JVM tiene problemas con el el archivo de Java (jar) generado y se bloqueará con un nivel muy bajo de errores JNI. Esto parece ser un error en el compilador de las versiones de JVM 1.4.x, esto pasa incluso si la versión destinada de JVM 1.1 es especificado al compilar las clases.

He aquí un ejemplo de los errores que se han experimentado:

A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in :
  'org/tanukisoftware/wrapper/WrapperManager.stopCommon (II)V': Interpreting method.
  Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi

Pude obtener ayuda de varias personas para poder producir las versiones liberadas para todas las plataformas compatibles y realmente no es posible forzar a todos que utilicen versiones anteriores de JDK para construir las distribuciones del Wrapper.

Si usted está experimentando problemas en el funcionamiento de la máquina JVM versión 1.2.x y el Wrapper, para solucionar el problema intente descargar el código fuente de la distribución y construya el archivo wrapper.jar utilizando su versión de JDK 1.2.x.

Si usted está experimentando esto por favor envíe un mensaje a La Lista de Correo del Wrapper disponible para usuarios. No estamos seguros cuantas personas siguen utilizando JVMs en la versión 1.2.x, si todavía es bastante común, puede que reconsideremos el error antes mencionado y enfocarnos en lo que se necesitaría para obtener las notas creadas en una máquina JVM versión 1.2.x.

Mi máquina JVM a veces se reinicia cuando el sistema está muy cargado.

Debido a que el Java Service Wrapper utiliza un mecanismo de "chequeo de respuesta" (pinging) para comprobar el estado de la máquina JVM. Es posible que el Wrapper piense que la máquina JVM está congelada cuando en realidad no es así. Esto pasa si otro proceso está consumiendo 100% del CPU durante más 30 segundos. Generando un resultado en el archivo de registro como a continuación se presenta y la máquina JVM reiniciará:

jvm 1    | 2001/12/01 12:23:23 | iniciar()
wrapper  | 2001/12/01 12:23:44 | Error al iniciar: Tiempo de espera: Esperando por una señal de la JVM. 
wrapper  | 2001/12/01 12:23:44 | JVM did not exit on request, terminated
wrapper  | 2001/12/01 12:23:49 | Iniciando JVM...
jvm 2    | 2001/12/01 12:23:50 | Inicializando...

La propiedad wrapper.ping.timeout=30 en conf/wrapper.log se puede utilizar para extender el tiempo de espera. Es importante tener en cuenta que esto también prolongará el tiempo que su aplicación quedará congelada en el caso que un problema real se presente.

Mi JVM se bloquea cuando se apaga después de hacer un Vertedero de Memoria.

El problema puede ser generado al configurar la propiedad wrapper.java.command a un archivo de órdenes (batch) en lugar de hacerlo directamente en java.exe. Al solicitar un Vertedero de Memoria, la señal de "BREAK" es enviada al proceso command.exe/shell en lugar de ser enviado al proceso Java. Reenviando la señal a la máquina JVM configurando un indicador interno informando que CTRL-C se ha presionado. Cuando el proceso hijo Java es terminado, inmediatamente se le pregunta al usuario si desea detener o continuar el proceso por lotes del archivo de órdenes.

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager Debug: Sent a packet STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | Wrapper  | 2009/10/23 14:30:56 | Error en el Apagado: Tiempo de espera: Esperando a que la JVM termine. 
ERROR  | Wrapper  | 2009/10/23 14:30:56 | JVM did not exit on request, terminated
STATUS | Wrapper  | 2009/10/23 14:30:57 | <-- El Wrapper se detuvo

Si va a tener que efectuar procesos adicionales antes o después de que la máquina JVM sea iniciada, la edición Profesional del Java Service Wrapper tiene la capacidad de hacer exactamente eso:Propiedades de Configuración de Eventos

No puedo usar el API llamado WrapperManager.requestThreadDump (Error 0x57)

Este problema es similar y causado por la misma razón que se mencionó anteriormente.

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: No se puede enviar el evento BREAK al proceso JVM: The parameter is incorrect. (0x57)

Si va a tener que efectuar procesos adicionales antes o después de que la máquina JVM sea iniciada, la edición Profesional del Java Service Wrapper tiene la capacidad de hacer exactamente eso:Propiedades de Configuración de Eventos

JBoss 6.* esta generando una gran cantidad de "ERRORES: Error al ser instalado..." Errores al iniciar y ejecutar mi aplicación con el Wrapper

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

La versión 6 de JBoss utiliza internamente una fábrica MBeanServer basada en org.jboss.system.server.jmx.MBeanServerBuilderImpl. Sin embargo, este no es compatible por defecto con la máquina JVM MBeanServerBuilder (javax.management.MBeanServerBuilder).

Hay dos opciones disponibles para solucionar esto: La primera opción es inhabilitar el registro de los MBeans del Wrapper, para usar esta opción por favor visite Método de Integración 1. La segunda opción es informar a la máquina JVM que use la fábrica "MBeanServer" que JBoss esta usando. Usted puede encontrar mas información visitando la página JMX.

El Wrapper está reportando un error/advertencia de validación al iniciar.

wrapper  | Una firma fue encontrada en "C:\wrapper-windows-x86-32-3.5.7-pro\bin\wra
pper.exe",  pero checksum tuvo un error: (Errorcode: 0x800b010a) 
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   Signer Certificate:
wrapper  |     Serial Number: 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: Tanuki Software Ltd.
wrapper  |   TimeStamp Certificate:
wrapper  |     Serial Number: 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: COMODO Time Stamping Signer
wrapper  |     Date of TimeStamp : 2010/12/19 22:32
wrapper  | El Wrapper se apagará!

A partir de la versión Wrapper 3.5.7, todos los sistemas binarios de Windows (por ejemplo wrapper.exe, wrapperW.exe y wrapper.dll) en todas las ediciones del Wrapper (Comunidad, Estándard y Profesional) están utilizando un código como firma para verificar el origen del archivo y que provenga de Tanuki Software. Si se detectará algún problema, el Wrapper terminará inmediatamente.

El error anterior se genera debido al desarrollo de nuestra firma con propósitos de autenticación - Comodo's UTN-USERFirst-Object. Los certificados instalados pueden ser investigados desde el Administrador de Certificaciones de Windows(Windows Certificate Manager) certmgr.msc. El certificado de UTN-USERFirst-Object debe estar presente en "Third Parties Root Certification Authorities\Certificates". Si el certificado raíz aún no esta disponible puede descargarlo a continuación:

https://support.comodo.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=79

Si se encuentra presente esto puede significar que la Política de Seguridad Local es muy estricta para permitir que la certificación sea verificada. Esta configuración se puede encontrar en la Política de Seguridad Local del servidor "Public Key Policies"\"Certificate Path Validation Settings" esto dará acceso a la (Root Certificate Store) "Third-Party Root CAs and Enterprise Root CAs". Si no esta presente/o no puede ser configurada, otra opción sería mover "UTN-USERFirst-Object Certificate" del archivo "Third Party Root CA" al archivo "Trusted Root Certificate Authorities".

En la versión del Wrapper 3.5.8, el Wrapper solo se apagará si la razón por la cual la firma no haya sido verificada haya sido causada directamente por el Wrapper en lugar del counter-signer.

En la versión del Wrapper 3.5.7, había un error que puede causar una violación de acceso cuando la verificación de la Firma falle y el Wrapper este tratando de reportar del error.

Solo puedo ejecutar servicios denominados -N- en Windows.

El Wrapper en sí no pone ninguna restricción sobre el número de instancias que se ejecuten en Windows al mismo tiempo. Debido a que el Wrapper y especialmente Java consumen varios recursos esto puede poner límites a las instancias que pueden ejecutarse en un sistema dado. El recurso más común que causa problemas es el montón del escritorio (Desktop Heap.) Para más información por favor visite la página ¿Cómo investigar y solucionar problemas de Windows Desktop Heap?