MSMQ con .NET 4.0 y el servidor 2008

Question

He .NET 4.0 aplicación portado desde la red 3.5 que utiliza net.msmq que se ejecuta en el servidor 2008 x64

Configuración

• Servicio net.msmq con address "net.msmq: //localhost/private/msmqdataservice.svc"
• net.msmq endpoing con la dirección "net.msmq: //localhost/private/msmqdataservice.svc"
• cola de MSMQ -> name = "$ private \ msmqdataservice.svc"

todo está trabajando en producción ahora con .net 3.5.

Instalé .NET 4.0 en el servidor y creé un sitio nuevo para organizar en el mismo cuadro.

Nueva configuración de puesta en escena es msmq

• Servicio net.msmq con la dirección "net.msmq: //localhost/private/staging/msmqdataservice.svc"
• net.msmq endpoing con la dirección "red. msmq: //localhost/private/staging/msmqdataservice.svc"
• cola de MSMQ -> name = "$ privada \ staging/msmqdataservice.svc"

Creado otra cola de sitio diferente.

Otro cambio que realicé con un nuevo sitio es que este es un sitio diferente en iis que escucha en una dirección IP diferente. He dejado net.msmq vinculante para 'localhost'. El sitio principal también tiene el mismo enlace para net.msmq -> 'localhost'. Creo que así es como debería ser. Por favor señale si necesita alguna configuración diferente.

Problema es mis solicitudes están haciendo en la cola, pero no para ser recogido por la aplicación que sólo se queda ahí

No hay ninguna indicación de algo malo en el registro. Lo único que veo en el registro relacionado con esto es una advertencia "msmqactivation no puede descubrir la cola". Aunque esta advertencia nunca he entendido correctamente, como hemos estado viendo esto siempre con todo bien con msmq en 3.5.

Cualquier cosa que pueda pensar está verificada y es correcta.

• El grupo de aplicaciones de la aplicación se está ejecutando como servicio de red y tiene acceso completo a la cola.
• servicio de activación net.msmq se está ejecutando con servicio de red
• probado diferentes convención de nombres de URL de servicio con el mismo resultado

Resumen

favor proporciona ninguna información sobre la configuración de múltiples sitios con red. msmq. Estoy usando el enlace net.msmq con value = 'localhost' para ambos sitios. Creo que es una identidad de nombre de máquina.

¿Alguna forma de diagnosticar este problema?

Cualquier otra cosa que pueda pensar puede ayudar.

Tuvimos que retrasar el lanzamiento ayer, ya que después de pasar como 100 horas hombre no podemos entender cuál es el problema. Tampoco puedo romperlo en mi máquina de desarrollo.

Editar

problema fue que después de crear nuevo sitio de la convención de nombres no funciona así

Servicio net.msmq con la dirección "net.msmq: //localhost/private/staging/msmqdataservice.svc" net.msmq endpoing con la dirección "net.msmq: //localhost/private/staging/msmqdataservice.svc" cola de MSMQ -> name = "$ \ staging privada/msmqdataservice.svc"

funcionó con el nombre del servicio net.msmq: //localhost/private/msmqdataservice.svc

pero ahora no puedo tener dos sitios usando exactamente el mismo punto final.

¿Alguna manera de tener el mismo punto final en dos sitios diferentes con diferente URL y cola diferente en la misma máquina?

Answer 1

¿Qué tal si usamos un puerto diferente? Puede usar el mismo nombre de host y decirle a WAS que se active en el nuevo puerto en un nuevo vdir o sitio.

Answer 2

Desafortunadamente, el oyente utiliza el nombre del servicio para determinar qué cola para escuchar lo que si su servicio de recepción se llama

MYOrganisation.Services.MyService.svc 

la cola debería llamarse

net.msmq://localhost/MYOrganisation.Services/MyService.svc 

Por lo tanto, la cola es llamado:

MYOrganisation.Services/MyService.svc 

Pruébelo y contácteme. Puedo publicar un ejemplo completo de la configuración que funciona.

Se me ocurre que aunque no tenga 2 puntos finales diferentes, podría tener el mismo servicio con un espacio de nombre diferente (o simplemente cambiar el nombre del servicio) escuchando una cola diferente. No es ideal, pero es lo único que encontré que funcionaría.

Answer 3

El URI de su punto extremo de servicio debe coincidir (más o menos, cf http://msdn.microsoft.com/en-us/library/ms789042.aspx) con el nombre de la cola. Entonces, aquí, la solución sería crear un directorio virtual llamado puesta en escena y poner su servicio allí.

En cuanto a la información de enlace, localhost señala que el servidor fue escuchado en la cola, por lo tanto, si las colas están instaladas en la misma máquina que IIS, este debe ser localhost.

Answer 4

La solución para mí fue instalar AppFabric para Windows Server v1.1. (Debe tenerlo para cualquier persona que use servicios WCF alojados en WAS/IIS o aplicaciones WF.)

Esto también corrigió un problema que estaba teniendo con el proceso WAS que se bloquea cada vez que creo una cola que no es WCF. El depurador Just-In-Time estaba tirando esto:

System.ServiceModel.EndpointNotFoundException was unhandled 
     Message=The service '~/nonWcfQueueName' does not exist. 
     Source=System.ServiceModel.Activation 
     StackTrace: 
      at System.ServiceModel.ServiceHostingEnvironment.NormalizeVirtualPath(String virtualPath) 
      at System.ServiceModel.Channels.MsmqHostedTransportManager.HostedBindingFilter.MatchFound(String host, String name, Boolean isPrivate) 
      at System.ServiceModel.Channels.MsmqBindingMonitor.MatchQueue(MatchState state) 
      at System.ServiceModel.Channels.MsmqBindingMonitor.ProcessFoundQueues(MessageQueue[] queues, Dictionary`2 knownQueues, Boolean isPrivate) 
      at System.ServiceModel.Channels.MsmqBindingMonitor.OnTimer(Object state) 
      at System.Runtime.IOThreadScheduler.ScheduledOverlapped.IOCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped) 
      at System.Runtime.Fx.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped* nativeOverlapped) 
      at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP) 
     InnerException: 

supongo que no muchas personas necesitan para mezclar colas WCF/no WCF en la misma máquina.Espero que esto salve a alguien del dolor que sufrí la semana pasada.

Answer 5

También un punto interesante: el servicio de adaptador net.msmq listner parece almacenar en caché el hecho de que no pudo acceder a la cola. Si intenta acceder a una cola para su servicio y falla, y luego agrega permisos para el adaptador de escucha net.msmq, aún no funcionará. Reinicié el servicio y luego la cola comenzó a ser vista nuevamente.