Проблема активации wcf MSMQ с .net 4.0 и сервером 2008

У меня есть приложение .net 4.0, перенесенное из net 3.5, которое использует net.msmq на сервере 2008 x64

Настройка

  • net.msmq Служба с адресом "net.msmq://localhost/private/msmqdataservice.svc"
  • net.msmq endpoing с адресом "net.msmq://localhost/private/msmqdataservice.svc"
  • очередь в MSMQ → name = "$ private\msmqdataservice.svc"

все работает над производством прямо сейчас с .net 3.5.

Я установил .net 4.0 на сервер и создал новый сайт для размещения в одном окне.

Новая настройка msmq установки

  • net.msmq Служба с адресом "net.msmq://localhost/private/staging/msmqdataservice.svc"
  • net.msmq endpoing с адресом "net.msmq://localhost/private/staging/msmqdataservice.svc"
  • очередь в MSMQ → name = "$ private\staging/msmqdataservice.svc"

Создана другая очередь для другого сайта.

Другое изменение, которое я сделал с новым сайтом, это другой сайт в iis с прослушиванием на другом ip-адресе. Я оставил привязку net.msmq к "localhost". На главном сайте также есть привязка для net.msmq → 'localhost'. Я думаю, что так должно быть. Пожалуйста, укажите, нужна ли какая-то другая конфигурация.

Проблема заключается в том, что мои запросы попадают в очередь, но не получаются приложением, которое просто остается там

В журнале нет никаких признаков чего-либо неправильного. Единственное, что я вижу в журнале, связанном с этим, - это предупреждение "msmqactivation не может обнаружить очередь". Хотя это предупреждение я никогда не понимал правильно, поскольку мы видели это всегда со всем прекрасным с msmq в 3.5.

Все, что я могу думать, проверяется, и это правильно.

  • Пул приложений приложений запущен как сетевой сервис и имеет полный доступ к очереди.
  • Служба активации net.msmq работает с сетевым сервисом
  • Пробовал другое соглашение об именах URL-адреса службы с таким же результатом

Резюме

Просьба представить информацию о настройке нескольких сайтов с помощью net.msmq. Я использую привязку net.msmq со значением = 'localhost' для обоих сайтов. Я думаю, что это механическое имя.

Любой способ диагностировать эту проблему?

Любая вещь, о которой вы можете подумать, может помочь.

Нам пришлось отложить выпуск вчера, так как, проведя 100 человеко-часов, мы не можем понять, в чем проблема. Также не удается заставить его разбиться на моей машине разработки.

Изменить

Проблема заключалась в том, что после создания нового соглашения об именах сайтов не работает, как

net.msmq Служба с адресом "net.msmq://localhost/private/staging/msmqdataservice.svc" net.msmq endpoing с адресом "net.msmq://localhost/private/staging/msmqdataservice.svc" очередь в MSMQ → name = "$ private\staging/msmqdataservice.svc"

он работал с именем службы net.msmq://localhost/private/msmqdataservice.svc

но теперь у меня не может быть двух сайтов, использующих точно такую ​​же конечную точку.

Любой способ иметь одну и ту же конечную точку на двух разных сайтах с разными URL-адресами и другой очереди на одной машине?

Ответы

Ответ 1

Исправление для меня заключалось в установке AppFabric для Windows Server v1.1. (Должно быть для тех, кто использует WAS/IIS для размещения служб WCF или WF-приложений.)

Это также исправило проблему, с которой я столкнулся с сбоем процесса WAS каждый раз, когда я создал очередь, отличную от WCF. Отладчик "Just-In-Time" выбрал следующее:

 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:

Я думаю, что многим людям не нужно смешивать очереди WCF/non-WCF на одной машине. Надеюсь, это спасет кого-то от боли, которую я пережил на прошлой неделе!

Ответ 2

Как использовать другой порт? Вы можете использовать одно и то же имя хоста и сообщить WAS для активации на новом порту в новом vdir или сайте.

Ответ 3

К сожалению, слушатель использует имя службы для определения очереди для прослушивания, поэтому, если ваша служба приема называется

MYOrganisation.Services.MyService.svc

ваша очередь должна быть вызвана

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

Итак, очередь вызывается:

MYOrganisation.Services/MyService.svc

Попробуй это и вернись ко мне. Я могу опубликовать полный пример конфигурации, которая работает.

Мне кажется, что даже если у вас может не быть двух разных конечных точек, вы можете иметь одну и ту же услугу с другим пространством имен (или просто переименовать службу), слушая другую очередь. Не идеально, но это единственное, что я нашел, что сработает.

Ответ 4

URI конечной точки службы должен соответствовать (более или менее, cf http://msdn.microsoft.com/en-us/library/ms789042.aspx) имя очереди. Таким образом, решение будет состоять в создании виртуального каталога с именем staging и размещении вашего сервиса там.

Что касается информации привязки, localhost указывает на сервер, то слушатель очереди должен быть прослушиванием, поэтому, если ваши очереди установлены на том же компьютере, что и IIS, это действительно является локальным хостом.

Ответ 5

Также интересный момент: служба адаптера net.msmq listner, похоже, кэширует тот факт, что не может получить доступ к очереди. Если он пытается получить доступ к очереди для вашей службы и терпит неудачу, а затем вы добавите разрешение для адаптера прослушивателя net.msmq, он все равно не будет работать. Я перезапустил службу, а затем снова зашла очередь.