NServiceBus Bus.Send (). Регистрация (обратный вызов) не работает на IIS / Windows Server 2008 - PullRequest
Новая
       29

NServiceBus Bus.Send (). Регистрация (обратный вызов) не работает на IIS / Windows Server 2008

4 голосов
/ 26 января 2012

Я боролся с этой проблемой уже несколько дней, и я просто не могу ее решить.

У меня есть простая веб-служба WCF, размещенная на IIS и Windows Server 2008 R2. Реализация веб-службы выглядит следующим образом: 

        var completionResult = new CompletionResult();
        var updateTextMessage = new UpdateText { TextTemplateId = textTemplateId, Text = text };

        var asyncResult = Global.Bus.Send(updateTextMessage).Register(x => completionResult = x.AsyncState as CompletionResult, null);
        asyncResult.AsyncWaitHandle.WaitOne(10000);

        if (completionResult.Messages != null && completionResult.Messages.Length > 0)
        {
            return ((UpdateTextResponse)completionResult.Messages[0]).ImageData;
        }

        return string.Empty;

Я знаю, что синхронное использование NSB считается плохим дизайном, но я просто экспериментирую, и мне бы очень хотелось, чтобы это сработало. Поэтому проблема заключается в том, что сообщение успешно отправляется на удаленную конечную точку, и сообщение успешно обрабатывается, но ответное сообщение просто теряется в эфире, когда удаленная конечная точка выполняет Bus.Reply. Я использую последнюю версию NSB, и странно то, что она отлично работает на моей машине для разработки Windows 7. Я убедился, что активный каталог отключен на обеих машинах. Я также запустил Wireshark на принимающей конечной точке и, конечно же, вижу входящее сообщение в данных пакета. Похоже, что что-то не работает с IIS. Я также переключил порог регистрации на DEBUG для обеих конечных точек, и ничего необычного не происходит. Конечная точка отправки говорит, что обычно "отправка сообщений в ..." Вот код в моем Application_Startup для веб-компонента: 

        Bus = NServiceBus.Configure.WithWeb()
            .Log4Net()
            .DefaultBuilder()
            .XmlSerializer()
            .MsmqTransport()
                .IsTransactional(false)
                .PurgeOnStartup(false)
            .UnicastBus()
                .ImpersonateSender(false)
            .CreateBus()
            .Start();

Вот конфиги для конечных точек: 

IIS Config (this side is not getting the response)

<MsmqTransportConfig InputQueue="Web.InputQueue" ErrorQueue="Web.ErrorQueue" MaxRetries="5" NumberOfWorkerThreads="1"/>
  <UnicastBusConfig>
    <MessageEndpointMappings>
      <add Messages="Messages" Endpoint="Node.Distributor.DataInputQueue"/>
    </MessageEndpointMappings>
  </UnicastBusConfig>

---------------------------------------------------------------

Endpoint which does the reply

<MsmqTransportConfig ErrorQueue="Node.ErrorQueue" InputQueue="Node.InputQueue" MaxRetries="5" NumberOfWorkerThreads="1"/>
<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue" DistributorDataAddress="Node.Distributor.DataInputQueue" />

Я также создал два автономных приложения NServiceBusHost для проверки связи, и он успешно работал. Я также жестко закодировал адрес возврата и заменил .Reply на .Send, но указав фактическое место назначения, и он все еще не работал. Итак, опять же, похоже, что это связано с IIS. Любая помощь будет принята с благодарностью!

Ответы [ 2 ]

1 голос
/ 28 января 2012

Я решил проблему. Оказывается, причина потери ответов была в том, что я ссылался на дистрибьютора как такового: 

<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue@10.1.4.58" DistributorDataAddress="Node.Distributor.DataInputQueue@10.1.4.58" />

Но оказывается, что дистрибьютору NServiceBus не нравятся IP-адреса. Поэтому я изменил это на следующее: 

<UnicastBusConfig DistributorControlAddress="Node.Distributor.ControlInputQueue@HOSTNAME" DistributorDataAddress="Node.Distributor.DataInputQueue@HOSTNAME" />

и это решило проблему. Мне также пришлось обновить файл hosts в Windows, поскольку NSB / MSMQ использует имена хостов. Я не уверен, является ли это ошибкой в ​​NServiceBus или это известная проблема, но она действительно должна быть задокументирована, если ее еще нет.

0 голосов
/ 26 января 2012

Звучит как разрешение очереди для меня.Проверьте свои очереди на стороне WCF, чтобы увидеть, может ли msmq даже доставить сообщение

...