MSMQ wcf проблема активации с .net 4.0 и сервером 2008 - PullRequest
10 голосов
/ 01 июня 2010

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

Настройка

  • net.msmq Сервис с адресом "net.msmq: //localhost/private/msmqdataservice.svc"
  • net.msmq конечная точка с адресом "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 с адресом "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 с адресом «net.msmq: //localhost/private/staging/msmqdataservice.svc» очередь в MSMQ -> name = "$ private \ staging / msmqdataservice.svc"

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

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

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

Ответы [ 5 ]

3 голосов
/ 05 октября 2012

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

Это также исправило проблему, возникающую при сбое процесса 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 на одной машине. Надеюсь, это спасет кого-то от боли, которую я пережил на прошлой неделе!

0 голосов
/ 03 июля 2013

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

0 голосов
/ 11 июня 2011

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

MYOrganisation.Services.MyService.svc

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

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

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

MYOrganisation.Services/MyService.svc

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

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

0 голосов
/ 26 августа 2011

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

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

0 голосов
/ 11 октября 2010

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

...