Porqué y cuándo pasar la carga útil de mensaje JMS por referencia

Cuando se envían mensajes de objetos o de bytes de gran tamaño, el coste en memoria y el uso del procesador para serializar, deserializar y copiar la carga de trabajo del mensaje puede ser muy significativo. Si se habilitan las propiedades pasar carga útil de mensajes por referencia en una fábrica de conexiones o especificación de activación, se indica al proveedor de mensajería predeterminado que altere temporalmente la especificación JMS 1.1 y reduzca u omita potencialmente esta copia de datos.

Segundo plano

La especificación JMS 1.1 indica que los mensajes de objeto se pasan por valor. Esto significa que un proveedor de JMS, como por ejemplo, el proveedor de mensajería predeterminado en WebSphere Application Server debe realizar una copia del objeto en ObjectMessage en el momento que el objeto se establece en la carga útil del mensaje, en el caso de la aplicación cliente modifique el objeto después de establecerlo. En la práctica, esto significa serializarlo, como si no hubiera otra forma totalmente segura de realizar una copia. La especificación también indica que cuando una aplicación de consumidor obtiene los datos del mensaje, el proveedor de JMS debe crear y devolver una copia de esos datos.

Si habilita las propiedades "pasar carga útil de mensajes por referencia" es posible que obtenga mejoras en la memoria y en el rendimiento para la mensajería JMS.

PRECAUCIÓN:
  • Las partes de la Especificación JMS que se omiten en estas propiedades se definen para garantizar la integridad de datos de mensajes.
  • Cualquiera de las aplicaciones JMS que utilizan estas propiedades deben seguir de forma estricta las reglas descritas más adelante en esta sección o se corre el riesgo de perder la integridad de los datos.
  • Debe leer y comprender todo este tema antes de habilitar estas propiedades.
Para pasar la carga útil de mensajes según su referencia, establezca las siguientes propiedades en las fábricas de conexiones y especificaciones de activación:
producerDoesNotModifyPayloadAfterSet (para fábricas de conexiones) o forwarderDoesNotModifyPayloadAfterSet (para especificaciones de activación)
Cuando esta propiedad está habilitada, el objeto o los mensajes de bytes producidos por la fábrica de conexiones o remitidos a través de la especificación de activación no se copian cuando se establecen en el mensaje y sólo se serializan cuando es absolutamente necesario. Las aplicaciones que envían estos mensajes no deben modificar los datos hasta que se hayan establecido en el mensaje.
consumerDoesNotModifyPayloadAfterGet
Cuando esta propiedad está habilitada, los mensajes de objeto recibidos a través de la fábrica de conexiones o la especificación de activación sólo se serializan cuando es absolutamente necesario. Las aplicaciones no deben modificar los datos obtenidos de estos mensajes.

Ventajas potenciales de pasar la carga útil de mensajes por referencia

La siguiente tabla muestra las condiciones en las que se pueden obtener ventajas en el rendimiento si habilita las propiedades "pasar carga útil de mensajes por referencia". En esta tabla se presupone lo siguiente:
  • Las aplicaciones JMS cumplen las reglas descritas en la sección siguiente de este tema.
  • Las aplicaciones generadora y consumidora de mensajes se ejecutan en la misma JVM (servidor), junto con el motor de mensajería que aloja el destino que estas aplicaciones utilizan.
Nota:
  • Si las aplicaciones se ejecutan en distintos servidores, o en la plataforma z/OS (donde WebSphere Application Server se ejecuta en varias JVM), los mensajes de objeto se serializan y no se obtienen ventajas de rendimiento para estos mensajes. Todavía se podrían lograr ventajas de mensajes de bytes.
  • Hay muchas condiciones de tiempo de ejecución internas que pueden provocar que los mensajes se serialicen, por lo que aunque su configuración satisface todas las condiciones descritas en este tema, podría obtener pocas o ninguna ventaja en el rendimiento al habilitar las propiedades "pasar carga útil de mensajes por referencia".
Tabla 1. Cómo determinan los factores de configuración y tiempo de ejecución qué datos se copian, dónde se copian y las ventajas de rendimiento potenciales.. La primera columna muestra el grado de ventajas de rendimiento potenciales. La segunda columna incluye los sucesos de configuración y tiempo de las ventajas potenciales. La tercera columna proporciona información como, por ejemplo, qué datos se copian y cuándo se copian los datos en función de los sucesos de configuración y tiempo de ejecución de las ventajas potenciales.
Grado de ventaja de rendimiento potencial Sucesos de configuración y tiempo de ejecución Cuándo se copian los datos
Ninguna ventaja potencial

Las propiedades "pasar carga útil de mensajes por referencia" no se habilitan (comportamiento predeterminado).

Los datos del mensaje de objeto se copian tan pronto se establecen en el mensaje y cuando se recuperan del mensaje.

Los datos del mensaje de bytes se copian tan pronto se establecen en el mensaje y cuando se recuperan del mensaje.

Alguna ventaja potencial
Las propiedades "pasar carga útil de mensajes por referencia" están habilitadas y se da una o las dos las siguientes condiciones:
  • Se tramita el mensaje de envío o de recepción.
  • El consumidor no está disponible cuando se genera el mensaje.

[AIX Solaris HP-UX Linux Windows][IBM i]Los datos de mensaje de objeto sólo se copian cuando es necesario.

Los datos de mensaje de bytes sólo se copian cuando es necesario.

Máximas ventajas potenciales
Las propiedades "pasar carga útil de mensajes por referencia" están habilitadas y se dan las siguientes condiciones:
  • No se tramita el mensaje de envío ni el mensaje de recepción.
  • El consumidor espera el mensaje cuando se genera (por ejemplo, si el consumidor es un bean controlado por mensaje).

[AIX Solaris HP-UX Linux Windows][IBM i]Los datos del mensaje de objeto puede que nunca se copien.

Los datos de mensaje de bytes sólo se copian cuando es necesario.

Reglas que deben cumplir las aplicaciones JMS

Las partes de la especificación JMS que se omiten en las propiedades "pasar carga útil de mensajes por referencia" se definen para garantizar la integridad de datos de mensajes. Si las aplicaciones JMS cumplen las reglas indicadas en la siguiente tabla, puede habilitar de forma segura las propiedades "pasar carga útil de mensajes por referencia" en las fábricas de conexiones y especificaciones de activación que las aplicaciones utilizan.

Si habilita las propiedades "pasar carga útil de mensajes por referencia" para las aplicaciones JMS que no cumplen estas reglas, las aplicaciones pueden recibir excepciones o, lo que es más importante, la integridad de los datos del mensaje puede estar en peligro.

Tabla 2. Reglas que deben cumplir las aplicaciones JMS, según tipo de aplicación. La primera columna lista los tipos de aplicaciones JMS. La segunda columna proporciona las reglas que la aplicación JMS debe seguir.
Tipo de aplicación Normas
Aplicación de generador JMS

Una aplicación de generador JMS que envía mensajes de objeto no debe alterar el objeto después de establecerlo en la carga útil del mensaje.

Una aplicación de generador JMS que envía mensajes de bytes:
  • debe grabar datos en el mensaje con una sola llamada a writeBytes(byte[]).
  • no debe alterar la matriz de bytes después de que se grabe en el mensaje.
Aplicación de consumidor JMS

Una aplicación de consumidor JMS que recibe mensajes de objeto no debe alterar la carga útil que obtiene del mensaje.

Aplicación de reenvío JMS
Nota: Una aplicación de reenvío JMS recibe un mensaje (a través de una fábrica de conexiones o, si es un bean controlado por mensajes, a través de una especificación de activación) y luego envía el objeto del mensaje a otro destino.
Una aplicación de reenvío JMS que sustituye la carga útil del mensaje recibido con una nueva carga útil:
  • (para mensajes de objeto) no deben alterar el objeto después de establecerlo en la carga útil del mensaje.
  • (para mensajes de bytes):
    • debe grabar datos en el mensaje con una sola llamada a writeBytes(byte[]).
    • no debe alterar la matriz de bytes después de que se grabe en el mensaje.

Cómo asegurarse de que los mensajes de objeto se pueden serializar

En condiciones de mensajería JMS normales (es decir, cuando las propiedades "pasar carga útil de mensajes por referencia" no están habilitadas), los datos de un mensaje de objeto se serializan en cuanto en objeto se pasa al sistema de mensajería, por ejemplo en set o send. Si la carga útil de mensajes no se puede serializar, se devuelve inmediatamente un mensaje de excepción a la aplicación cliente.

Cuando las propiedades "pasar carga útil de mensajes por referencia" están habilitadas, se acepta la carga útil de mensajes en la aplicación cliente sin intentar serializarla. Si más adelante el sistema descubre que los datos no se pueden serializar, el sistema ya no podrá informar a la aplicación cliente que ha enviado el mensaje, y debido a que los datos no son serializables, el sistema no podrá persistir ni transmitir el mensaje completo. El mensaje y sus propiedades se almacenan, pero los datos de usuario del mensaje (la carga útil) no se puede almacenar y se descarta. Si hay problemas de serialización cuando el sistema intenta convertir un mensaje de objeto en un gráfico de datos para una mediación, la carga útil de mensajes se descarta y la mediación recibe un mensaje con el valor de datos establecido en nulo.

Si los datos no se pueden serializar, se pierden. Por lo tanto, primero debe probar la configuración sin habilitar las propiedades "pasar carga útil de mensajes por referencia", para comprobar que todos los datos enviados al sistema sean serializables.

Cuando el sistema descubre que un mensaje de objeto no se puede serializar, graba el siguiente mensaje de error (JMS_IBM_ExceptionMessage) en el archivo SystemOut.log, donde "{0}" se sustituye por el nombre de clase del objeto erróneo:
Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
CWSIK0200E: Un objeto de clase "{0}" se ha establecido en la carga útil de mensajes pero no se puede serializar.
Explicación: Un mensaje de objeto enviado con el distintivo producerDoesNotModifyPayloadAfterSet habilitado en esta fábrica de conexiones se ha enviado con una carga útil que el sistema no ha podido serializar. Estos datos de mensajes se han perdido.
Acción: inhabilite producerDoesNotModifyPayloadAfterSet en la fábrica de conexiones. Sin el distintivo habilitado, la aplicación JMS que establece el objeto en el mensaje recibirá inmediatamente todas las excepciones de serialización.
Las siguientes propiedades de excepción se utilizan para indicar que un objeto de datos no puede serializarse y que se ha descartado. Las aplicaciones JMS pueden averiguar lo que ha sucedido en las propiedades JMS_IBM_Exception. Las mediaciones pueden averiguar lo que ha sucedido en las propiedades JMS_IBM_Exception y SI_Exception.
JMS_IBM_ExceptionReason
SIRCConstants.SIRC0200_OBJECT_FAILED_TO_SERIALIZE
JMS_IBM_ExceptionTimestamp
La hora en la que el objeto no ha podido serializarse, en formato System.currentTimeMillis().
JMS_IBM_ExceptionMessage
El mensaje CWSIK0200E, como se ha descrito anteriormente.
SI_ExceptionReason
SIRC0200_OBJECT_FAILED_TO_SERIALIZE
SI_ExceptionTimestamp
La hora en la que el objeto no ha podido serializarse, en formato System.currentTimeMillis().
SI_ExceptionInserts
Una matriz de serie que contiene una entrada. La entrada contiene el nombre de clase del objeto.
Nota: La explicación más probable en lo que se refiere al motivo por el que los objetos de datos no se han podido serializar es que ha grabado sus propios métodos writeObject() o writeExternal() y no ha comprobado completamente cada opción (por ejemplo, las excepciones NullPointer o las excepciones ArrayIndexOutOfBounds).

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjn_passbyref
File name: cjn_passbyref.html