En esta sección se describen algunos problemas habituales que pueden surgir cuando se desarrollan flujos de mensajes. Contiene consejos para resolver los problemas:
Este error hace que el mensaje se dirija al terminal de anomalías.
Tal vez haya conectado accidentalmente el terminal de anomalías del nodo MQInput a un nodo sucesivo en vez de hacerlo al terminal de salida. El terminal de salida es el terminal intermedio de los tres. Se descartan los mensajes dirigidos a un terminal de salida no conectado.
Si se ha conectado el terminal de anomalías del nodo MQInput, por ejemplo, a un nodo MQOutput, estos mensajes no aparecerán.
La conexión de un nodo a un terminal de anomalías de cualquier nodo indica que ha designado el flujo de mensajes responsable de todo el proceso de errores. Si conecta un terminal de anomalías a un nodo MQOutput, el flujo de mensajes omite los errores que se puedan producir.
Para obtener más información, consulte la sección Utilización del rastreo.
Esta acción produce una entrada de rastreo de usuario de cada nodo que el mensaje visite y sólo de dichos nodos.
En las plataformas distribuidas, puede recuperar las entradas de rastreo utilizando el mandato mqsireadlog, formatearlas utilizando el mandato mqsiformatlog y visualizar los registros formateados para comprobar la vía de acceso del mensaje a través del flujo de mensajes. Para obtener más información sobre estos mandatos, consulte la sección Mandatos.
Para z/OS, edite y envíe el trabajo BIPJLOG en COMPONENTPDS para ejecutar mqsireadlog y mqsiformatlog para procesar rastreos. Para obtener más información sobre los mandatos del programa de utilidad, consulte la sección Trabajos de programas de utilidad de z/OS.
Envíe del mensaje de nuevo al flujo de mensajes. El nivel de rastreo de depuración genera mucha más información detallada sobre por qué el mensaje está tomando esta ruta, y encontes, se pueden determinar las razones de las acciones realizadas por el flujo de mensajes.
No olvide desactivar el rastreo cuando haya resuelto el problema o sino, el rendimiento resultará perjudicado.
En general:
Si el flujo de mensajes tiene vías de acceso que no son anomalías, pero que no finalizan en una cola de salida (u otro almacenamiento permanente) store), indica que el flujo de mensajes no ha fallado y el mensaje no se restituye ni se transfiere a un destino alternativo (por ejemplo, el terminal de captación, la cola de mensajes no entregados o la cola de restitución de la cola).
SQL0954C No hay suficiente almacenamiento en el almacenamiento dinámico de la aplicación para procesar la sentencia.En z/OS, se podría devolver un SQLSTATE de HY014 con un código SQL de -99999, indicando que el proceso DataFlowEngine ha alcanzado el límite de proceso de DB2 z/OS de 254 manejadores de sentencias SQL preparadas.
Por motivos de rendimiento, una vez preparada la sentencia, la sentencia y el manejador se guardan en una antememoria para reducir el número de llamadas a la función SQLPrepare. Si la sentencia ya se encuentra en la antememoria, se devuelve el manejador de sentencias para que se pueda volver a ejecutar con parámetros recién enlazados.
La serie de caracteres de la sentencia se utiliza para realizar la búsqueda de antememoria. Utilizando series de caracteres SQL codificados en fábrica que son ligeramente diferentes para cada mensaje, la sentencia no se encuentra en la antememoria y siempre se ejecuta una función SQLPrepare (y se abre un nuevo cursor ODBC). Cuando utilice sentencias PASSTHRU, utilice marcadores de parámetros para que se pueda utilizar la misma sentencia de SQL para cada mensaje procesado, con los parámetros enlazándose durante la ejecución. Este método es más eficaz en términos de recursos de base de datos y, para las sentencias que se ejecutan reiteradamente, es más rápido.
No obstante, siempre es posible utilizar marcadores de parámetros o tal vez desee crear dinámicamente series de caracteres de sentencias SQL durante la ejecución. Esto conduce potencialmente a que muchas sentencias SQL exclusivas se coloquen en antememoria. La antememoria propiamente dicha no aumenta demasiado ya que estas sentencias generalmente no son por sí mismas grandes, pero muchas asignaciones de memorias pequeñas pueden producir lafragmentación de memoria.
Para un flujo de mensajes determinado, un nodo habitual requiere aproximadamente 2KB del espacio de pila de la hebra. Por omisión, hay por consiguiente, un límite de aproximadamente 500 nodos dentro de un único flujo de mensajes en la plataforma UNIX y 1000 nodos en la plataforma Windows. Este límite podría ser mayor o menor, dependiendo del tipo de proceso que se esté realizando dentro de cada nodo.
El valor de esta variable de entorno se aplica a los intermediarios; por consiguiente, se utiliza MQSI_THREAD_STACK_SIZE para cada hebra que se crea dentro de un proceso DataFlowEngine. Si al grupo de ejecución tiene demasiados flujos de mensajes se le han asignado demasiados flujos de mensajes y se establece un valor MQSI_THREAD_STACK_SIZE grande, el proceso DataFlowEngine necesitará una gran cantidad de almacenamiento para la pila.
Video_Test#FCMComposite_1_1 ComIbmMQInputNode , Video_Test.VIDEO_XML_IN
Si necesita analizar o modificar los datos contenidos dentro de un mensaje WebSphere MQ Everyplace, utilice un MQeMbMsgObject. Este proporciona un paralelo con los mensajes de WebSphere MQ estándar: puede establecer campos como por ejemplo, ID de correlación, y hay un campo que se puede analizar utilizando cualquier analizador de WebSphere Business Integration Event Broker.
Conceptos relacionados
Mensajes de WebSphere MQ Everyplace
Flujos de mensajes
Tareas relacionadas
Desarrollo de aplicaciones de flujos de mensajes
Manejo de errores en flujos de mensajes
Utilización del rastreo
Solución de problemas
Referencia relacionada
WebSphere MQ Mobile Transport
Flujos de mensajes
Nodo MQInput
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
au16530_ |