Compartir a través de

errores de Server-Side

  • Artículo

El agente de escucha y el reproductor trabajan juntos para tratar los mensajes dudosos. Si se produce un error en una transacción que se está reproduciendo, Message Queuing devuelve el mensaje de entrada a la cola de entrada. El jugador anula la transacción si recibe un HRESULT erróneo del componente de servidor o si detecta una excepción. Si el problema persiste, el agente de escucha podría bucle continuamente en el siguiente patrón:

  • Quita la cola del mensaje.
  • Crea una instancia del objeto
  • Sufre una reversión
  • Vuelve a poner el mensaje en la parte superior de la cola.

El servicio de componentes en cola controla este error mediante una serie de colas de reintento específicas de la aplicación. Creado cuando se instala el componente, hay siete colas para cada aplicación, como se indica a continuación:

  1. Cola de entrada normal. El nombre de esta cola es el nombre de la aplicación COM+. Se trata de una cola pública de Message Queuing.

  2. Primera cola de reintento. Los mensajes se mueven aquí si se produce un error en la transacción repetidamente al procesar mensajes de la cola de entrada normal. Los mensajes de esta cola se procesan después de un minuto. Se puede reintentar un mensaje tres veces en esta cola antes de moverse a la parte posterior de la segunda cola de reintento. Esta cola se denomina ApplicationName_0. Esta cola es una cola privada de Message Queuing.

  3. Segunda cola de reintento. Los mensajes se mueven aquí si se produce un error en la transacción repetidamente al procesar mensajes de la primera cola de reintento. Los mensajes de esta cola se procesan después de dos minutos. Se puede reintentar un mensaje tres veces en esta cola antes de moverse a la parte posterior de la tercera cola de reintento. Esta cola se denomina ApplicationName_1. Esta cola es una cola privada de Message Queuing.

  4. Tercera cola de reintento. Los mensajes se mueven aquí si se produce un error en la transacción repetidamente al procesar mensajes de la segunda cola de reintento. Los mensajes de esta cola se procesan después de cuatro minutos. Se puede reintentar un mensaje tres veces en esta cola antes de moverse a la parte posterior de la cuarta cola de reintento. Esta cola se denomina ApplicationName_2. Esta cola es una cola privada de Message Queuing.

  5. Cuarta cola de reintento. Los mensajes se mueven aquí si se produce un error en la transacción repetidamente al procesar mensajes de la tercera cola de reintento. Los mensajes de esta cola se procesan después de ocho minutos. Se puede reintentar un mensaje tres veces en esta cola antes de moverse a la quinta cola de reintento. Esta cola se denomina ApplicationName_3. Esta cola es una cola privada de Message Queuing.

  6. La quinta cola de reintento. Los mensajes se mueven aquí si se produce un error en la transacción repetidamente al procesar mensajes de la cuarta cola de reintento. Los mensajes de esta cola se procesan después de dieciséis minutos. Se puede reintentar un mensaje tres veces en esta cola antes de moverse a la cola de reposo final. Esta cola se denomina ApplicationName_4. Se trata de una cola privada de Message Queuing.

  7. Una cola de reposo final específica de la aplicación. Los mensajes se mueven aquí si la transacción se anula repetidamente cuando se intenta en la quinta cola de reintento. Esta cola se denomina ApplicationName_DeadQueue. Se trata de una cola privada de Message Queuing. Un agente de escucha de cola no atiende la cola de reposo final. Los mensajes permanecen aquí hasta que se mueven manualmente (quizás mediante la utilidad de mover mensajes de componentes en cola) o se purgan mediante el Explorador de Message Queuing.

Los mensajes que no son reproducibles porque está claro que todos los reintentos producirán un error se pueden mover directamente a la cola de reposo final específica de la aplicación sin estar avanzados a través de todos los niveles de reintento.

El jugador emite un evento COM+ para notificar a las partes interesadas que no se pueden reproducir mensajes. Los eventos COM+ se emiten en las situaciones siguientes:

  • Cuando se anula una transacción
  • Cuando se mueve un mensaje de una cola a otra
  • Cuando se deposita un mensaje en la cola de reposo final

Los mensajes se pueden modificar antes de pasar de una cola a otra. El mecanismo de seguridad de componentes en cola COM+ permite mover un mensaje a las colas de reintento y, a continuación, reinsertar en la cola de entrada inicial de la aplicación. Para obtener más información sobre la seguridad de los componentes en cola, consulte Seguridad de componentes en cola.

Las colas de reintento se crean junto con la cola de aplicaciones principal cuando la aplicación está marcada como en cola por la herramienta de administración servicios de componentes o mediante las funciones del SDK administrativo de COM+. El servicio de componentes en cola permite flexibilidad en el mecanismo de reintento al permitir que se eliminen las colas de reintento. Por ejemplo, si se eliminan todas las colas de reintento, se moverá un mensaje que anula de forma persistente directamente desde la cola de aplicaciones a la cola de reposo final específica de la aplicación. Al quitar una o varias de las colas de reintento, se puede reducir el número y la longitud de los reintentos. Si se quitan las colas de la secuencia de reintento, el tiempo de las colas restantes corresponde a la posición de la secuencia de colas de reintento. Por ejemplo, si quita la cola de reintento ApplicationName_1, ApplicationName_2 y ApplicationName_3, los mensajes de ApplicationName_4 se procesarán como si la cola fuera la segunda cola de reintento.

El mecanismo de reintento está diseñado para completar un mensaje si es posible. En algunos casos, puede que no sea posible que el mensaje se realice correctamente. Por ejemplo, un cliente puede intentar retirar dinero de una cuenta que no tiene fondos suficientes. En estas circunstancias, puede controlar el error de varias maneras, incluidas las siguientes:

  • Generación de un diagnóstico y emisión de una advertencia
  • Creación de una transacción de compensación
  • Omitir el problema y descartar el mensaje

Al igual que los errores persistentes del lado cliente, el servicio de componentes en cola permite asociar una clase de excepción a un componente. La clase de excepción está asociada al componente mediante la pestaña Avanzadas de la página de propiedades del componente de la herramienta de administración servicios de componentes o mediante las funciones administrativas com+. La clase de excepción permite al desarrollador tener el control después de reintentar un mensaje y antes de que ese mensaje se mueva a la cola de reposo final específica de la aplicación. Para obtener más información sobre la clase de excepción, vea Errores de Client-Side persistentes.

A continuación se muestra la secuencia de eventos para el control de excepciones del lado servidor:

  1. El mensaje se mueve a través de las colas de reintento específicas de la aplicación disponibles.
  2. Se produce un error en el último reintento de la última cola de reintentos.
  3. El servicio de componentes en cola recupera el componente de destino del mensaje y comprueba si hay una clase de excepción.
  4. El tiempo de ejecución crea una instancia de la clase de excepción.
  5. El tiempo de ejecución consulta IPlaybackControl en la clase de excepción.
  6. El tiempo de ejecución llama a IPlaybackControl::FinalServerRetry en la clase de excepción.
  7. El tiempo de ejecución reproduce todas las llamadas de propiedad y método desde el mensaje a la clase de excepción.
  8. Si los pasos del 4 al 6 no se realizan correctamente, el tiempo de ejecución mueve el mensaje a la cola de reposo final específica de la aplicación.

Si necesita intervenir en el proceso descrito anteriormente o necesita mover un mensaje dudoso fuera de su cola de reposo final, use la utilidad de mover mensajes. Para obtener más información sobre la utilidad de mover mensajes, consulte Control de errores.

Errores del lado cliente

Errores de Client-Side persistentes