Обработка ядовитых сообщений в WCF MSMQ 4.0 - PullRequest
Новая
       14

Обработка ядовитых сообщений в WCF MSMQ 4.0

9 голосов
/ 15 декабря 2009

Я пытаюсь обработать подозрительные сообщения в WCF с помощью транспорта MSMQ.

Я перешел по ссылке ниже для создания оригинальных и ядовитых сервисов.

http://msdn.microsoft.com/en-us/library/aa395218.aspx

Единственное отличие состоит в том, что вместо собственного хостинга я разместил 2 службы в IIS с одним хост-проектом.

Ниже приведена конфигурация обеих служб. 

<services>
  <service behaviorConfiguration="MainMSMQWCFService.Service1Behavior"
    name="MainMSMQWCFService.OrderProcessorService">
    <endpoint address="net.msmq://localhost/private/servicemodelsamplespoison"
      binding="netMsmqBinding" bindingConfiguration="PoisonBinding"
      contract="MainMSMQWCFService.IOrderProcessor" />
  </service>
  <service behaviorConfiguration="MainMSMQWCFService.PoisonHandlingServiceBehavior"
    name="MainMSMQWCFService.PoisonHandlingService">
    <endpoint address="net.msmq://localhost/private/servicemodelsamplespoison;poison" 
              binding="netMsmqBinding"
              bindingConfiguration="PoisonBinding2"
              contract="MainMSMQWCFService.IOrderProcessor">
    </endpoint>
  </service>
</services>

Обе службы работают правильно.

Проблема заключается в том, что когда сообщение помещается в очередь отравления, служба отравления не обрабатывает сообщение. Я наблюдал за сообщениями в очереди Poison, они нацелены только на оригинальный сервис. тогда как ядовитая служба может их обработать? Пройдя через MSDN, я узнал, что, установив атрибут поведения службы, канал WCF решает эту проблему. Следующий параграх объясняет то же самое.

"Сообщения в очереди подозрительных сообщений - это сообщения, адресованные службе, обрабатывающей сообщение, которая может отличаться от конечной точки службы вредоносных сообщений. Поэтому, когда служба подозрительных сообщений читает сообщения из очереди, WCF канальный уровень обнаруживает несоответствие в конечных точках и не отправляет сообщение. В этом случае сообщение адресовано службе обработки заказов, но принимается службой подозрительных сообщений. Продолжать получать сообщение, даже если сообщение адресовано с другой конечной точкой, мы должны добавить ServiceBehavior для фильтрации адресов, где критерий соответствия должен соответствовать любой конечной точке службы, которой адресовано сообщение. Это необходимо для успешной обработки сообщений, которые вы читаете из очереди вредоносных сообщений. "

Но моя служба отравления не обрабатывает отравленные сообщения?

Я не могу выяснить проблему.

Ответы [ 2 ]

4 голосов
/ 05 августа 2010

У меня такая же проблема.

Мне было интересно, так ли это, потому что при размещении сервисов netMsmq в IIS имя очереди должно совпадать с именем сервиса. В случае начальной очереди сообщений это нормально (например, очередь будет чем-то вроде private / SimpleService / Service1.svc), но тогда очередь ядовитых имен называется private / SimpleService / Service1.svc; toxic, которая явно не соответствует названию службы отравления.

У меня были сэмплы, работающие нормально при самостоятельном размещении. Эта проблема, кажется, только с хостингом IIS.

Если это проблема, то, боюсь, у меня нет решения ...

Обновление:

Этот комментарий от

http://msdn.microsoft.com/en-us/library/ms789042(v=VS.90).aspx

Предполагается, что проблема в том, что я думал:

"Приложение, размещенное на WAS, не может быть активировано на основе сообщений в системной очереди, например общесистемной очереди недоставленных сообщений, или вложенных очередей, таких как подозрительные вложенные очереди. Это ограничение для этой версии продукта "

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

1) Написать код в реализации сервиса для перемещения сообщений в альтернативную очередь при сбое 2) Используйте триггер для передачи сообщений из очереди подозрительных сообщений в другую очередь, чтобы служба, размещенная на IIS, прослушивала 3) Разместите службу ядовитых сообщений в пользовательском EXE-файле вместо IIS

2 голосов
/ 10 января 2012

Я недавно столкнулся с этим с IIS7. Да, по умолчанию приложение, размещенное в WAS, не работает в очередях отравления. Однако я полагаю, что в IIS существует способ размещения службы WCF, которая обнаруживает подозрительные сообщения. Я думаю об этом, что служба ядовитых сообщений на самом деле является вспомогательной службой основной службы WCF и в некотором смысле зависит от основной службы. Чтобы разместить субсервис в WCF, я реализовал пользовательский ServiceHostFactory. Внутри ServiceHostFactory я перезаписываю события OnOpening и OnClosing основного хоста службы, чтобы открывать и закрывать службу вредоносных сообщений. Вот пример кода: 

public class HostFactory : ServiceHostFactory
{ 
    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        SomeServiceHost host = new SomeServiceHost(serviceType, baseAddresses);
        host.PoisonMsmqServiceType = typeof(PoisonHandler);
        return host;
    }
}

public class SomeServiceHost : ServiceHost
{
    private ServiceHost poisonMsmqServiceHost;


    public Type PoisonMsmqServiceType { get; set; }

     public SomeServiceHost(Type serviceType, params Uri[] baseAddresses)
    : base(serviceType, baseAddresses) { }

    protected override void OnOpening()
    {
        base.OnOpening();

        if (this.PoisonMsmqServiceType != null)
        {
            this.poisonMsmqServiceHost = new ServiceHost(this.PoisonMsmqServiceType);
            this.poisonMsmqServiceHost.Open();
        }
    }

    protected override void OnClosing()
    {
        base.OnClosing();

        if (this.poisonMsmqServiceHost != null)
        {
            this.poisonMsmqServiceHost.Close();
            this.poisonMsmqServiceHost = null;
        }
    }
}

После этого, просто установите атрибут 'Factory' в вашем файле .svc с вашим собственным классом фабрики хостов, и он должен позаботиться об обработке ядовитых сообщений.

...