Solución de problemas de la mensajería en cola

Esta sección contiene preguntas comunes y ayuda para solucionar problemas con el uso de colas en Windows Communication Foundation (WCF).

Preguntas frecuentes

P: He usado WCF Beta 1 y he instalado la revisión de MSMQ. ¿Debo quitar la revisión?

R: Sí. Esta revisión ya no se admite. WCF ahora funciona en MSMQ sin un requisito de revisión.

P: Hay dos enlaces para MSMQ: NetMsmqBinding y MsmqIntegrationBinding. ¿Qué debería utilizar y cuándo?

R: Use NetMsmqBinding cuando desee usar MSMQ como transporte para la comunicación en cola entre dos aplicaciones de WCF. Utilice MsmqIntegrationBinding cuando desee utilizar aplicaciones de MSMQ existentes para comunicarse con nuevas aplicaciones de WCF.

P: ¿Tengo que actualizar MSMQ para usar los enlaces NetMsmqBinding y MsmqIntegration?

R: No. Ambos enlaces funcionan con MSMQ 3.0 en Windows XP y Windows Server 2003. Ciertas características de los enlaces se vuelven disponibles al actualizar a MSMQ 4.0 en Windows Vista.

P: ¿Qué características de los enlaces NetMsmqBinding y MsmqIntegrationBinding están disponibles en MSMQ 4.0 pero no en MSMQ 3.0?

R: Las características siguientes están disponibles en MSMQ 4.0 pero no en MSMQ 3.0:

• La cola de mensajes no enviados personalizada solo se admite en MSMQ 4.0.

• MSMQ 3.0 y 4.0 administran los mensajes dudosos de manera diferente.

• Sólo MSMQ 4.0 admite la lectura de transacción remota.

P: ¿Puedo usar MSMQ 3.0 en un lado de una comunicación en cola y MSMQ 4.0 en el otro lado?

R: Sí.

P: Quiero integrar aplicaciones de MSMQ existentes con nuevos clientes o servidores WCF. ¿Necesito actualizar ambos lados de mi infraestructura de MSMQ?

R: No. No tiene que actualizar a MSMQ 4.0 en ningún lado.

Solución de problemas

Esta sección contiene las respuestas a la mayoría de problemas más comunes. Algunos problemas que son limitaciones conocidas también se describen en las notas de la versión.

P: Estoy intentando usar una cola privada y obtengo la excepción siguiente: System.InvalidOperationException: la dirección URL no es válida. La dirección URL para la cola no puede contener el carácter '$'. Utilice la sintaxis en net.msmq://machine/private/queueName para direccionar una cola privada.

R: Compruebe el identificador uniforme de recursos (URI) en la configuración y en el código. No utilice el carácter "$" en el URI. Por ejemplo, para dirigirse a una cola privada llamada OrdersQueue, especifique el identificador URI como net.msmq://localhost/private/ordersQueue.

P: Al llamar a ServiceHost.Open() en mi aplicación en cola, se produce la excepción siguiente: System.ArgumentException: una dirección base no puede contener una cadena de consulta de URI. ¿Por qué?

R: Compruebe el identificador URI de la cola en el archivo de configuración y en el código. Mientras que las colas de MSMQ admiten el uso del carácter "?", los URI lo interpretan como el principio de una consulta de cadena. Para evitar este problema, use nombres de cola que no contengan el carácter "?".

P: Mi envío se realizó correctamente pero en el receptor no se invoca ninguna operación de servicio. ¿Por qué?

R: Para determinar la respuesta, use la lista de comprobación siguiente:

• Compruebe que los requisitos de cola transaccional sean compatibles con las convicciones especificadas. Tenga en cuenta los principios siguientes:

  • Puede enviar mensajes duraderos (datagramas y sesiones) con garantías de tipo "exactamente una vez" (ExactlyOnce = true) solo a una cola transaccional.

  • Solo puede enviar las sesiones con "exactamente una" convicción.

  • Se requiere una transacción para recibir mensajes en una sesión de una cola transaccional.

  • Puede enviar o recibir los mensajes volátiles o duraderos (solo datagramas) sin garantías (ExactlyOnce = false) solo a una cola no transaccional.

• Compruebe la cola de mensajes no enviados. Si encuentra los mensajes allí, determine por qué no se entregaron.

• Compruebe la conectividad o los problemas de direccionamiento de las colas de salida.

P: He especificado una cola de mensajes no enviados personalizada, pero cuando inicio la aplicación emisora, se produce una excepción que indica que no se encuentra la cola de mensajes no enviados o la aplicación emisora no tiene permiso para obtener acceso a la cola de mensajes no enviados. ¿Por qué ocurre esto?

R: El identificador URI de la cola de mensajes no enviados personalizada debe incluir "localhost" o el nombre de equipo en el primer segmento; por ejemplo, net.msmq://localhost/private/myAppdead-letter queue.

P: ¿Siempre es necesario definir una cola de mensajes no enviados personalizada o hay una cola de mensajes no enviados predeterminada?

R: Si las garantías son "exactamente una vez" (ExactlyOnce = true) y si no se especifica una cola de mensajes no enviados personalizada, el valor predeterminado es una cola de mensajes no enviados transaccional para todo el sistema.

Si no hay garantías (ExactlyOnce = false), el valor predeterminado es la ausencia de funcionalidad de cola de mensajes no enviados.

P: Mi servicio inicia SvcHost.Open con un mensaje que indica "ListenerFactory no puede cumplir los requisitos de EndpointListener". ¿Por qué?

A. Compruebe su contrato de servicios. Quizás haya olvidado colocar "IsOneWay =true" en todas las operaciones de servicio. Las colas solo admiten las operaciones de servicio unidireccionales.

P: Hay mensajes en la cola pero no se invoca ninguna operación de servicio. ¿Cuál es el problema?

R: Determine si el host de servicio tiene algún error. Lo puede comprobar examinando el seguimiento o implementando IErrorHandler. El host de servicio, de forma predeterminada, tiene errores si se detecta un mensaje dudoso.

P: Hay mensajes en la cola pero no se activa mi servicio en cola hospedado en la web. ¿Por qué?

R: El motivo más común son los permisos.

1. Asegúrese de que el proceso NetMsmqActivator se esté ejecutando y la identidad del proceso NetMsmqActivator se lea y busque el permiso en la cola.

2. Si NetMsmqActivator está supervisando las colas en un equipo remoto, asegúrese de que NetMsmqActivator no se ejecute con un token restringido. Para ejecutar NetMsmqActivator con un token sin restricciones:

   sc sidtype NetMsmqActivator unrestricted
   

Para problemas del host web no relacionados con la seguridad, consulte: Hospedaje web de una aplicación en cola.

P: ¿Cuál es la manera más fácil de tener acceso a las sesiones?

R: Establezca AutoComplete=true en la operación que se corresponda con el último mensaje de la sesión y establezca AutoComplete=false en todas las operaciones de servicio restantes.

P: ¿Por qué mi servicio inicia una excepción ProtocolException cuándo lee de una cola que contiene mensajes de sesión en cola y mensajes de datagrama en cola?

R: Hay una diferencia fundamental en la forma en la que se componen los mensajes de sesión en cola y los mensajes de datagrama en cola. Debido a esto, un servicio que está esperando leer un mensaje de la sesión en cola no puede recibir un mensaje del datagrama en cola y un servicio que espera leer un mensaje del datagrama en cola no puede recibir un mensaje de la sesión. Intentar leer ambos tipos de mensajes de la misma cola provoca la excepción siguiente:

System.ServiceModel.MsmqPoisonMessageException: The transport channel detected a poison message. This occurred because the message exceeded the maximum number of delivery attempts or because the channel detected a fundamental problem with the message. The inner exception may contain additional information.
---> System.ServiceModel.ProtocolException: An incoming MSMQ message contained invalid or unexpected .NET Message Framing information in its body. The message cannot be received. Ensure that the sender is using a compatible service contract with a matching SessionMode.

La cola de mensajes no enviados del sistema, así como cualquier cola de mensajes no enviados personalizada, es particularmente susceptible a este problema si una aplicación envía mensajes de la sesión en cola y mensajes del datagrama en cola desde el mismo equipo. Si no se puede enviar un mensaje correctamente, se mueve a la cola de mensajes no enviados. Bajo estas circunstancias, es posible tener mensajes de sesión y datagrama en la cola de mensajes no enviados. No hay ninguna manera de separar ambos tipos de mensajes en tiempo de ejecución al leer de una cola, por consiguiente, las aplicaciones no deberían enviar mensajes de sesión en cola y mensajes de datagrama en cola desde el mismo equipo.

Integración de MSMQ: Solución de problemas específicos

P: Cuando envío un mensaje o cuando abro el host de servicio, obtengo un error que indica que el esquema es erróneo. ¿Por qué?

R: Al usar el enlace de integración de MSMQ, debe usar el esquema msmq.formatname. Por ejemplo, msmq.formatname:DIRECT=OS:. \private $ \OrdersQueue. Pero al especificar la cola de mensajes no enviados personalizada, debe utilizar el esquema de net.msmq.

P: Cuando uso un nombre de formato público o privado y abro el host de servicio en Windows Vista, obtengo un error. ¿Por qué?

R: El canal de integración de WCF en Windows Vista comprueba si se puede abrir una subcola para la cola principal de la aplicación con el fin de administrar los mensajes dudosos. El nombre de la subcola se deriva de un identificador URI de msmq.formatname pasado al cliente de escucha. El nombre de la subcola en MSMQ solo puede ser un nombre de formato directo. Aquí radica el error. Cambie el URI de la cola a un nombre de formato directo.

P: Al recibir un mensaje de una aplicación de MSMQ, el mensaje permanece en la cola y la aplicación de WCF receptora no lo lee. ¿Por qué?

R: Compruebe si el mensaje tiene cuerpo. Si el mensaje no tiene ningún cuerpo, el canal de integración de MSMQ omite el mensaje. Implemente IErrorHandler para recibir notificaciones de las excepciones y comprobar las trazas.

Solución de problemas relacionados con la seguridad

P: Cuando ejecuto el ejemplo que usa un enlace predeterminado en modo de grupo de trabajo, los mensajes parecen enviarse pero nunca se reciben.

R: De manera predeterminada, los mensajes se firman con un certificado interno de MSMQ que requiere el servicio de directorio Active Directory. En modo del grupo de trabajo, puesto que Active Directory no está disponible, la firma de los mensajes falla. Por lo tanto, el mensaje aterriza en la cola de mensajes no enviados y provoca el error, como "Firma no válida".

La solución alternativa es desactivar la seguridad. Esto se hace estableciendo Mode = None para que funcione en modo de grupo de trabajo.

Otra solución alternativa es recibir MsmqTransportSecurity de la propiedad Transport y establecerlo en Certificatey establecer el certificado de cliente.

Todavía otra solución alternativa es instalar MSMQ con integración de Active Directory.

P: Cuando envío un mensaje con un enlace predeterminado (seguridad de transporte activada) en Active Directory a una cola, obtengo el mensaje "No se encuentra el certificado interno". ¿Cómo puedo corregirlo?

R: Esto significa que se debe renovar el certificado del remitente en Active Directory. Para hacerlo, abra Panel de control, Herramientas administrativas, Administración de equipos, haga clic con el botón derecho en MSMQ y seleccione Propiedades. Seleccione la pestaña Certificado de usuario y haga clic en el botón Renovar.

P: Cuando envío un mensaje mediante Certificate y especifico el certificado que se va a usar, aparece el mensaje "Certificado no válido". ¿Cómo puedo corregirlo?

R: No puede usar un almacén de certificados del equipo local en modo de certificado. Tiene que copiar el certificado del almacén de certificados del equipo al almacén del usuario actual utilizando el complemento del certificado. Para obtener el complemento del certificado:

1. Haga clic en Inicio, seleccione Ejecutar, escriba mmc y haga clic en Aceptar.

2. En Microsoft Management Console, abra el menú Archivo y seleccione Agregar/quitar complemento.

3. En el cuadro de diálogo Agregar/quitar complemento, haga clic en el botón Agregar.

4. En el cuadro de diálogo Agregar un complemento independiente, seleccione Certificados y haga clic en Agregar.

5. En el cuadro de diálogo del complemento Certificados, seleccione Mi cuenta de usuario y haga clic en Finalizar.

6. Luego, agregue un segundo complemento Certificados utilizando los pasos anteriores, pero esta vez seleccione Cuenta de equipo y haga clic en Siguiente.

7. Seleccione Equipo Local y haga clic en Finalizar. Ahora puede arrastrar y colocar certificados del almacén de certificados del equipo al almacén del usuario actual.

P: Cuando mi servicio lee de una cola de otro equipo en modo de grupo de trabajo, se produce una excepción "acceso denegado".

R: En modo de grupo de trabajo, para que una aplicación remota obtenga acceso a la cola, la aplicación debe tener permiso de acceso a la cola. Agregue "Inicio de sesión anónimo" a la lista de control de acceso (ACL) de la cola y proporciónele permiso de lectura.

P: Cuando un cliente del servicio de red (o cualquier cliente que no tenga una cuenta de dominio) envía un mensaje en cola, se produce un error en el envío que indica que el certificado no es válido. ¿Cómo puedo corregirlo?

R: Compruebe la configuración del enlace. El enlace predeterminado tiene la seguridad de transporte de MSMQ activada para firmar el mensaje. Desactívela.

Recepciones de transacción remotas

P: Cuando tengo una cola en el equipo A y un servicio de WCF que lee los mensajes de una cola en el equipo B (escenario de recepción de transacción remota), los mensajes no se leen de la cola. La información de seguimiento indica que hubo un fallo en la recepción con el mensaje "No se puede importar la transacción". ¿Qué puedo hacer para solucionarlo?

A: Hay tres razones posibles para esto:

• Si está en modo del dominio, la recepción de transacciones remotas requiere el acceso de red de Microsoft DTC (Coordinador de transacciones distribuidas) (MSDTC). Puede habilitarlo mediante Agregar/quitar componentes.

  

• Compruebe el modo de autenticación para comunicarse con el administrador de transacciones. Si está en modo de grupo de trabajo, debe seleccionar "No se requiere autenticación". Si está en modo de dominio, debe seleccionar "Autenticación mutua requerida".

  

• Asegúrese de que MSDTC esté en la lista de excepciones en la configuración del Firewall de conexión a Internet.

• Asegúrese de que usa Windows Vista. MSMQ en Windows Vista admite la lectura de transacciones remotas. MSMQ en versiones anteriores de Windows no admite la lectura de transacciones remotas.

P: Cuando el servicio que lee de la cola es un servicio de red, por ejemplo, en un host web, ¿por qué obtengo una excepción de acceso denegado al leer de la cola?

R: Se debe agregar el acceso de lectura del servicio de red a la ACL de la cola para garantizar que un servicio de red pueda leer de la cola.

P: ¿Puedo usar el servicio de activación de MSMQ para activar aplicaciones basadas en mensajes en una cola de un equipo remoto?

R: Sí. Para ello, debe configurar el servicio de activación de MSMQ para que se ejecute como un servicio de red y agregar el acceso del servicio de red a la cola en el equipo remoto.

Utilizar los enlaces personalizados de MSMQ con ReceiveContext habilitado

Al utilizar un enlace personalizado de MSMQ con ReceiveContext habilitado, al procesar un mensaje entrante se utilizará un subproceso del grupo de subprocesos porque MSMQ nativo no admite la finalización de E/S para recepciones ReceiveContext asincrónicas. Esto se debe a que, al procesar este tipo de mensaje, se utilizan transacciones internas para ReceiveContext y MSMQ no admite el procesamiento asincrónico. Para evitar este problema, puede agregar SynchronousReceiveBehavior al punto de conexión para forzar el procesamiento sincrónico, o establecer MaxPendingReceives en 1.