Archive for the ‘Software’ 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

¿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í)