Archive for the ‘Servidores de aplicaciones’ Category

Modificar Parámetros Timeout JTA / BPEL en WLS (Oracle Weblogic Server 11g)

Jueves, enero 26th, 2012

Antes de empezar, debo decirles que esto lo probé en una máquina con Oracle BPM 11g (11.1.1.4) y el problema que presentaba es que a los 5 minutos un servicio web que ejecutaba un PL-SQL en la BD a través de un DB Adapter misteriosamente se cancelaba. A continuación les muestro el log que aparecía en el servidor SOA:

Caused by: BINDING.JCA-11811
Stored procedure invocation error.
Error while trying to prepare and execute the SCHEMA01.PKG01.PLSQL01 API.
An error occurred while preparing and executing the SCHEMA01.PKG01.PLSQL01 API.
Cause: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation
ORA-06512: at "SCHEMA01.PKG01", line 1206
ORA-06512: at "SCHEMA01.PKG01", line 1176
ORA-06512: at line 1

Check to ensure that the API is defined in the database and that the parameters match the signature of the API.  This exception is considered retriable, likely due to a communication failure.  Because the global transaction is rolling back the invoke must be retried in a new transaction, restarting from the place of the last transaction commit.  To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml).

    at oracle.tip.adapter.db.exceptions.DBResourceException.createXARetriableException(DBResourceException.java:670)
    at oracle.tip.adapter.db.exceptions.DBResourceException.createEISException(DBResourceException.java:642)
    at oracle.tip.adapter.db.sp.SPUtil.createResourceException(SPUtil.java:175)
    at oracle.tip.adapter.db.sp.AbstractStoredProcedure.execute(AbstractStoredProcedure.java:131)
    at oracle.tip.adapter.db.sp.SPInteraction.executeStoredProcedure(SPInteraction.java:141)
    at oracle.tip.adapter.db.DBInteraction.executeStoredProcedure(DBInteraction.java:1102)
    at oracle.tip.adapter.db.DBInteraction.execute(DBInteraction.java:247)
    at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAInteractionInvoker.executeJcaInteraction(JCAInteractionInvoker.java:311)
    ... 102 more

Para corregir este error de timeout obtuve cierta información que espero sea de utilidad para alguien más. Los pasos para cambiar los parámetros de timeout tanto en JTA como en BPEL son:

1. Configuración syncMaxWaitTime: Esta propiedad controla el tiempo máximo que se espera un resultado en un proceso sincronizado.

• Iniciar sesión en EM como administrador.
• Abrir SOA y click derecho sobre “soa-infra”.
• Seleccionar: SOA Administration -> BPEL Properties
• Dar click sobre “More BPEL Configuration Properties…”
• Localizar el atributo syncMaxWaitTime y cambiarlo.

2. Configuración del tiempo de transacción de EJB de BPEL: Permite modificar las propiedades de tiempo de espera (timeout) para la aplicación SOA, ignorando la configuración global especificada en los parámetros JTA.
• Acceda a la consola de administración de Oracle WebLogic.
• Haga clic Deployments.
• Ampliar soa-infra –> EJB.
• Los siguientes EJBs deben actualizarse:

BPELActivityManagerBean
BPELDeliveryBean
BPELDispatcherBean
BPELEngineBean
BPELFinderBean
BPELInstanceManagerBean
BPELProcessManagerBean
BPELSensorValuesBean
BPELServerManagerBean

• Puede consultar en la pestaña de configuración el timeout para los beans que coincidan con el filtro “EJB*BPEL” (podría haber más beans si su versión es diferente).
• Haga clic en Guardar.
• Reiniciar Oracle WebLogic Server.

3. Ajuste del timeout de transacción global a nivel de dominio WebLogic: Esta propiedad controla el tiempo de espera para las transacciones activas. Si la transacción está todavía en estado “activo” después de ese tiempo, automáticamente se revierte (rolled back).

• Acceda a la consola de administración de Oracle WebLogic.
• Haga clic en Servicios -> JTA.
• Cambie el valor de segundos del tiempo de espera (timeout, por defecto es 30).
• Haga clic en Guardar.
• Reinicie Oracle WebLogic Server.

En mi caso se modifiqué los valores de timeout JTA a:

• Timeout Seconds: 6000
• Completion Timeout: -1 (en opciones avanzadas)
• Maximum Duration of XA Calls: 6000000 (en opciones avanzadas)

Las transacciones se establecen a 6000 segundos que equivale a 1.6 horas.

Algunos enlaces de interés (parte de la información fue obtenida de estas fuentes):

  • http://forums.oracle.com/forums/thread.jspa?threadID=2279364
  • http://sudhakarsoa.blogspot.com/2011/03/how-do-you-configure-transaction.html

Ejecutar Java en plataformas .NET y MONO

Jueves, septiembre 30th, 2010

Sí, como lo oyen: Java en .NET.

No sé si todos lo sepan pero .NET tiene un Common Language Runtime o CLR (Lenguaje común en tiempo de ejecución) que es el componente de máquina virtual de la plataforma .NET de Microsoft.

Mono es un proyecto Open Source iniciado por Ximian y actualmente impulsado por Novell (tras la adquisición de Ximian) para crear un grupo de herramientas libres, compatibles con .NET, según lo especificado por el ECMA (y proporciona un CLR, además de soporte a algunos lenguajes como C#, MonoBasic, GTK# etc).

Alguna vez escuché a los evangelizadores de .NET decir que su máquina virtual es una evolución natural de la Java Virtual Machine (JVM). ¿Por qué? Porque Java produce bytecodes que se interpretan en la JVM. Si los bytecodes son portables porque la implementación de la JVM es un estándar (independiente del Sistema Operativo o hardware) es lógico hacer lo mismo con cualquier lenguaje y esto haría que cualquier lenguaje pueda funcionar como Java, es decir independiente del Sistema Operativo y del hardware. Así nace CLR, una máquina virtual para múltiples lenguajes. Creado CLR lo único que faltaría es el compilador que genere código intermedio (llamado Common Intermediate Language – CIL) para el lenguaje que se desee ejecutar en el CLR.

[ Breve paréntesis: ¿Por qué no hacemos un compilador que nos permita programar con Logo o Basic y ejecutar lo programado en la JVM? No he visto ningún proyecto similar. Y la idea no deja de ser interesante y teóricamente posible.]

Bueno, buscando, era obvio que era cuestión de tiempo para que crearan eso que permitiese ejecutar Java dentro del CLR.
El proyecto es IKVM.NET:

IKVM.NET es una implementación de Java para Mono y Microsoft.NET Framework. Incluye los siguientes componentes:

  • Una máquina virtual de Java implementada en. NET
  • Implementación de las clases básicas de Java en .NET
  • Herramientas que permiten la interoperabilidad entre Java y .NET

Lo bueno, es que funciona bien con aplicaciones de consola (habrá que ver el rendimiento, en MONO y en CLR .NET). Lo malo, es que no funcionan bien las interfaces gráficas (olvídate de usar Swing). Como alternativa creo que podrías crear un programa híbrido con clases Java, usando interfaces gráficas .NET.

Los links de interes:

Mono & Java
Interfaces gráficas Java en Mono… que decepción

Usar PHP y JEE juntos

Miércoles, septiembre 29th, 2010

Desde hace unos días me ha saltado la duda de qué usar en un nuevo desarrollo: Si es mejor PHP o JEE, o mejor usar PHP para la presentación y JEE para programar el core.

Cómo recordarán, tengo una entrada respecto a ‘Delphi for PHP’ (D4PHP) un producto que ofrece una forma rápida de desarrollar interfaces gráficas en PHP.

Tengo que decirles que una de mis motivaciones principales es lograr un entorno de desarrollo donde de manera visual pueda editar las interfaces gráficas, como lo que ofrece D4PHP. Claro, me gustaría más si se puede desarrollar en un producto Open Source y en el lenguaje Java, pero quiero evaluar de forma objetiva las opciones disponibles en el mercado.

Es indudable que las ventajas de menor consumo de memoria hacen deseable a PHP. PHP ya tiene muchos sistemas para administración de contenidos (páginas) que pueden ser modificados o ampliados. Sin embargo, creo que JEE (y la pléyade de frameworks alrededor) permiten mucha flexibilidad y orden en el desarrollo de las cosas.

Sí, hay ventajas y desventajas que habrá que evaluar individualmente en cada caso. Y en el tema de recursos, rentar un hosting sencillo o rentar un servidor virtual tiene una diferencia de precio. Y si es un hosting Java o PHP también varía el precio. Qué buscamos con el servidor:

  • Tener un tiempo de respuesta aceptable.
  • Soportar la operación de los múltiples usuarios concurrentes.
  • Un uptime alto.

Algunas variables a tomar en cuenta para decidirse por el hosting son:

  • Cantidad de memoria disponible.
  • Procesador disponible en el servidor.
  • Espacio en disco.
  • Experiencia de los desarrolladores.
  • Conocimiento del lenguaje con el que se desarrollará, etc.

Navegando por la web buscando mas pistas sobre como evaluar correctamente el uso de PHP o JEE encontré un artículo algo viejito de IBM con una forma de integrar PHP y J2EE en Websphere Application Server (artículo del año 2005).

Las ligas útiles son:

Espero les sea de ayuda.
 
 
 
PD: Encontré un framework que me permite diseñar interfaces gráficas web en Java como si se tratasé de Swing. ¿Han oído de GWT? Vean el artículo al respecto, aquí.
 
 
 

Parámetros de memoria al iniciar Java

Jueves, agosto 26th, 2010

Un proceso Java (servidor de aplicaciones, Java Web Start applications, Applets, etc.) requiere una máquina virtual Java (JVM) para su ejecución. Como parte de la configuración se pueden ajustar los valores que mejoran el uso del sistema de la JVM.

Pasaré a explicar los parámetros que más he usado:

    -Xms: El valor por defecto son 64Mb. Este valor controla el tamaño inicial del almacenamiento dinámico Java. Si se ajusta correctamente este parámetro se reduce la actividad general de recogida de basura y se mejoran la productividad y el tiempo de respuesta del servidor. Para algunas aplicaciones, el valor por omisión de esta opción puede ser demasiado bajo, lo que causa un número elevado de recogidas de basura sin importancia, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria.
Valor por omisión: 64 MB
Valor recomendado: Específico de la carga de trabajo pero superior al valor por omisión.
Uso: -Xms256m establece el tamaño del almacenamiento dinámico en 256 megabytes
    -Xmx: Este valor controla el tamaño máximo del almacenamiento dinámico Java. Si se ajusta correctamente este parámetro se reduce la actividad general de recogida de basura y se mejoran la productividad y el tiempo de respuesta del servidor. Para algunas aplicaciones, el valor por omisión de esta opción puede ser demasiado bajo, lo que causa un número elevado de recogidas de basura sin importancia. Si la aplicación supera el tamaño máximo de memoria que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError. No conviene asignar a este parámetro el máximo de la memoria de la máquina porque si ya no queda memoria física disponible se pueden producir escrituras en memoria asignada a otros programas y provocar un auténtico lío.
Valor por omisión: 128 MB
Valor recomendado: Específico de la carga de trabajo pero superior al valor por omisión.
Uso: -Xmx512m establece el tamaño del almacenamiento dinámico en 512 megabytes
    -XX:PermSize=: Permite modificar la sección del almacenamiento dinámico reservado para la generación permanente que contiene todos los datos reflectivos de la JVM. Este tamaño debe aumentarse para optimizar el rendimiento de las aplicaciones que carga y descarga dinámicamente muchas clases. Esto agiliza la carga de aplicaciones, sobre todo en el caso de aplicaciones que hagan uso intensivo de este tipo de memoria (Spring, Hibernate, etc.). Si se especifica un valor de 128 MB megabytes se elimina la actividad general de aumentar esta parte del almacenamiento dinámico.
Valor recomendado: 128 MB
Uso: XX:PermSize=128m establece el tamaño de perm en 128 megabytes.
    -XX:MaxPermSize=: Tamaño máximo de la memoria de tipo PermGen a 128Mb. El valor por defecto son 64Mb. Si la aplicación supera el tamaño máximo de memoria para este tipo que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError: PermGen space. El valor necesario para este parámetro siempre suele ser menor que el de la memoria de tipo heap.
Valor por omisión: 64 MB
Valor recomendado: Específico de la carga de trabajo pero superior al valor por omisión.
Uso: -XX:MaxPermSize=128m establece el tamaño del almacenamiento dinámico en 128 megabytes

A continuación se dan distintos ejemplos de modificación de la memoria de distinta forma. No es necesario especificar todos los parámetros, se pueden especificar todos o ninguno (y se tomarían los valores por defecto)

Ejecución de un jar:

java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  -jar example.jar

Ejecución de una clase:

java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  com.programacionenjava.examples.MemoryExample

Vía Java Web Start

Panel de control -> Java:
-Xms128M -Xmx256M -XX:PermSize=128M -XX:MaxPermSize=256M

Mediante Apache Ant

<java classname="com.coresware.MyExample" fork="yes" spawn="true">
<jvmarg value="-Xms128m"/>
<jvmarg value="-Xmx512m"/>
<jvmarg value="-XX:PermSize=128m"/>
<jvmarg value="-XX:MaxPermSize=128m"/>
<classpath refid="execution.classpath"/>
</java>

Por parámetros pasados al sistema operativo:

En Windows:

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m

En Linux:

JAVA_OPTS="$JAVA_OPTS -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m"

Fuentes:

  • Aumentar el tamaño de memoria de la máquina virtual en Java
  • Websphere Application Server: Ajuste de máquinas virtuales Java
  • How do you determine a good MaxPermSize?
  • ¿Iniciaste JBoss y no se pueden conectar desde otras máquinas?

    Jueves, agosto 26th, 2010

    Ayer estuve haciendo pruebas a una aplicación desplegada en JBoss en mi máquina. Localmente las pruebas funcionaban pero al intentar conectar desde otra máquina no se podían conectar a la aplicación en mi máquina. El comando “ping” funcionaba. Unos días antes las pruebas estuvieron funcionando pero la única diferencia es que las pruebas anteriores se realizaron con Tomcat 6 y ahora estoy usando JBoss 4.2.

    El problema era configurar a JBoss para que admita conexiones de todos lados. Investigando un poco en foros encontré la solución.

    Si usas JBoss desde consola debes modificar el archivo run.bat o run.sh, encontrarás en el script una parte que dice:

    "%JAVA%" %JAVA_OPTS% ^
       -Djava.endorsed.dirs="%JBOSS_ENDORSED_DIRS%" ^
       -classpath "%JBOSS_CLASSPATH%" ^
       org.jboss.Main %*
    

    Debe modificarse a:

    "%JAVA%" %JAVA_OPTS% ^
       -Djava.endorsed.dirs="%JBOSS_ENDORSED_DIRS%" ^
       -classpath "%JBOSS_CLASSPATH%" ^
       org.jboss.Main -b0.0.0.0 %*
    

    (El 0.0.0.0 puede ser modificado si deseas colocar una IP específica)

    Otra forma es iniciarlo desde la línea de comandos pasando el parámetro:

    run -b 0.0.0.0

    Pero como estoy ejecutando JBoss desde Eclipse necesito pasar el parámetro a través de Eclipse así que modifiqué los parámetros con los que inicia el servidor en modo de depuración (similar si lo quieres iniciar en el modo ‘normal’):

    Modificando la configuración de la depuración en Eclipse

    Modificando la configuración de la depuración en Eclipse

    Configurando JBoss en Eclipse

    Configurando JBoss para que permita conexiones de cualquier URL

    Como ven en la imagen, también hay parámetros de memoria modificados para que el JBoss no muera en el intento de iniciar.

    (Más detalles sobre estos parámetros de memoria aquí)