2009-12-15 7 views
9

Ich versuche, die Giftnachrichten in WCF mit MSMQ-Transport zu behandeln.Poison Message-Behandlung in WCF MSMQ 4.0

Ich folgte dem unten stehenden Link für die Erstellung der ursprünglichen und Gift-Dienste. statt Selbst Hosting, ich war Gastgeber den 2 servces in IIS mit einem einzigen Host-Projekt

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

Der einzige Unterschied ist.

Die Konfiguration der beiden Dienste ist unten.

Beide Dienste werden ordnungsgemäß ausgeführt.

Das Problem ist, wenn die Nachricht in die Gift-Warteschlange gestellt wird, verarbeitet der Gift-Service die Nachricht nicht. Ich habe die Nachrichten in der Poison-Warteschlange beobachtet, sie richten sich nur an den ursprünglichen Dienst. Wie kann der Giftdienst sie dann verarbeiten? Nachdem ich MSDN durchlaufen habe, habe ich erfahren, dass der WCF-Kanal dieses Problem durch das Festlegen des Dienstverhaltenattributs behoben hat. Der folgende Paragraph erklärt das Gleiche.

"Nachrichten in der Warteschlange für Nachrichtenmeldungen sind Nachrichten, die an den Dienst gerichtet sind, der die Nachricht verarbeitet, der sich vom Endpunkt des Poison-Nachrichtendiensts unterscheiden kann. Wenn der Nachrichtendienst Meldungen aus der Warteschlange liest WCF-Channel-Layer findet die Nichtübereinstimmung in Endpunkten und sendet die Nachricht nicht In diesem Fall wird die Nachricht an den Auftragsverarbeitungsdienst adressiert, wird aber vom Giftnachrichtendienst empfangen, um die Nachricht auch dann weiter zu empfangen, wenn die Nachricht adressiert ist Zu einem anderen Endpunkt müssen wir ein ServiceBehavior hinzufügen, um Adressen zu filtern, bei denen das Übereinstimmungskriterium jedem Dienstendpunkt entspricht, an den die Nachricht adressiert ist. Dies ist erforderlich, um Nachrichten erfolgreich zu verarbeiten, die Sie aus der Warteschlange für nicht verarbeitete Nachrichten lesen. "

Aber mein Giftdienst verarbeitet die vergifteten Nachrichten nicht?

Ich bin nicht in der Lage, das Problem herauszufinden.

+0

Hmmmm, Sie können nur HTTP-Bindungen in IIS hosten. Meinst du WAS? –

Antwort

4

Ich habe das gleiche Problem.

Ich frage mich, ob dies der Grund dafür ist, dass der Warteschlangenname beim Hosting der netMsmq-Dienste in IIS mit dem Dienstnamen übereinstimmen muss. Im Fall der anfänglichen Nachrichtenwarteschlange ist dies in Ordnung (zB wäre die Warteschlange etwas wie private/SimpleService/Service1.svc), aber dann heißt die Giftwarteschlange private/SimpleService/Service1.svc; poison, was offensichtlich nicht der Fall ist Passen Sie den Namen des Giftdienstes an.

Ich hatte Proben, die gut funktionieren, wenn sie selbst gehostet werden. Dieses Problem scheint nur bei IIS-Hosting zu sein.

Wenn dies das Problem ist, dann habe ich keine Lösung Ich habe Angst ...

Update:

Dieser Kommentar von

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

schlägt vor, dass das Problem ist, wie Ich dachte:

"Eine WAS-gehostete Anwendung kann nicht basierend auf Nachrichten in einer Systemwarteschlange, wie der System-Wid aktiviert werden e Warteschlange für nicht zustellbare Nachrichten oder Unterwarteschlangen, z. B. Giftunterwarteschlangen.Dies ist eine Einschränkung für diese Version des Produkts“

Ich glaube nicht, es ist möglich, eine alternative benutzerdefinierte Gift Nachrichtenwarteschlange, so die Alternativen sind:

1) Code in der Service-Implementierung zu Verschieben Sie Nachrichten in eine alternative Warteschlange bei Fehler 2) Verwenden Sie einen Trigger, um Nachrichten aus der Warteschlange Giftmaus in eine andere Warteschlange zu übertragen und einen IIS-gehosteten Dienst zu hören 3) Hosten Sie Ihren Nachrichtendienst in einer benutzerdefinierten EXE anstelle von IIS

+0

Microsoft sollte in der net.msmq-Bindung ** eine benutzerdefinierte Funktion für die Warteschlange für benutzerdefinierte Nachrichten hinzufügen –

2

Ich bin kürzlich in diesem mit IIS7.Ja, standardmäßig, WAS-gehostete Anwendung funktioniert nicht auf Gift-Warteschlangen, aber ich glaube Es gibt eine Möglichkeit, den WCF-Dienst in IIS zu hosten, der vergiftete Nachrichten erkennt. Die Art und Weise, wie ich darüber nachdenke, ist, dass der Giftnachricht-Dienst wirklich ein Teildienst des WCF-Hauptdienstes ist und vom Hauptdienst abhängig ist. Um den Subservice in WCF zu hosten, habe ich Custom ServiceHostFactory implementiert. In ServiceHostFactory überschreibe ich OnOpening- und OnClosing-Ereignisse des Hauptdiensthosts, um den Giftnachrichtendienst zu öffnen und zu schließen. Hier ist ein Beispielcode:

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; 
     } 
    } 
} 

Danach setzen Sie einfach die ‚Factory‘ Attribut auf Sie mit Ihrem eigenen Host-Factory-Klasse-Datei .SVC und es sollte das Gift Nachricht für Sie Umgang kümmern.