MSMQ wcf Aktivierungsproblem mit .net 4.0 und Server 2008

Question

Ich habe eine .net 4.0-Anwendung von net 3.5 portiert, die net.msmq auf einem Server 2008 x64 verwendet

Einrichtung

• net.msmq Dienst mit Adresse "net.msmq://localhost/private/msmqdataservice.svc"
• net.msmq Endung mit Adresse "net.msmq://localhost/private/msmqdataservice.svc"
• Warteschlange in MSMQ -> Name = "$privat \msmqdataservice.svc "

alles funktioniert jetzt in der Produktion mit .net 3.5.

Ich installierte .net 4.0 auf dem Server und erstellte eine neue Website für Staging auf der gleichen Box.

Die neue Staging-Msmq-Einrichtung lautet

• net.msmq Dienst mit Adresse "net.msmq://localhost/private/staging/msmqdataservice.svc"
• net.msmq endet mit der Adresse "net.msmq://localhost/private/staging/msmqdataservice.svc"
• Warteschlange in MSMQ -> Name = "$privat \staging /msmqdataservice.svc"

Eine weitere Warteschlange für eine andere Website erstellt.

Eine weitere Änderung, die ich mit der neuen Website vorgenommen habe, ist, dass es sich um eine andere Website in iis handelt, die auf eine andere IP-Adresse hört. Ich habe die net.msmq Bindung auf 'localhost' gesetzt. Auch die Hauptseite hat die gleiche Bindung für net.msmq -> 'localhost'. Ich denke, so sollte es auch sein. Bitte weisen Sie mich darauf hin, wenn Sie eine andere Konfiguration benötigen.

Das Problem ist, dass meine Anfragen in der Warteschlange landen, aber nicht von der Anwendung abgeholt werden, sondern einfach dort bleiben.

Im Protokoll gibt es keinen Hinweis auf einen Fehler. Das einzige, was ich in diesem Zusammenhang im Protokoll sehe, ist die Warnung "msmqactivation cannot discover queue". Obwohl diese Warnung habe ich nie richtig verstanden, da wir dies immer mit alles in Ordnung mit msmq in 3.5 gesehen haben.

Alles, was ich mir vorstellen kann, wird überprüft und ist korrekt.

• Der App-Pool der Anwendung wird als Netzwerkdienst ausgeführt und hat vollen Zugriff auf die Warteschlange.
• Der net.msmq-Aktivierungsdienst wird mit dem Netzwerkdienst ausgeführt
• Ich habe eine andere Namenskonvention für die Service-Url ausprobiert - mit demselben Ergebnis

Zusammenfassung

Bitte geben Sie einen Einblick in die Einrichtung mehrerer Sites mit net.msmq. Ich verwende net.msmq Bindung mit Wert = 'localhost' für beide Standorte. Ich denke, es ist die Identität des Maschinennamens.

Gibt es eine Möglichkeit, dieses Problem zu diagnostizieren?

Alles, was Ihnen sonst noch einfällt, kann helfen.

Wir mussten die Veröffentlichung gestern verschieben, da wir nach etwa 100 Arbeitsstunden nicht herausfinden konnten, was das Problem ist. Auch kann es nicht machen es brechen in meiner Entwicklung Maschine.

Editar

Das Problem war, dass nach dem Erstellen einer neuen Website die Namenskonvention nicht funktioniert wie

net.msmq Dienst mit der Adresse "net.msmq://localhost/private/staging/msmqdataservice.svc" net.msmq Endpunkt mit Adresse "net.msmq://localhost/private/staging/msmqdataservice.svc" Warteschlange in MSMQ -> Name = "$privat \staging /msmqdataservice.svc"

es funktionierte mit dem Dienstnamen net.msmq://localhost/private/msmqdataservice.svc

aber jetzt kann ich nicht zwei Sites haben, die genau denselben Endpunkt verwenden.

Gibt es eine Möglichkeit, denselben Endpunkt auf zwei verschiedenen Websites mit unterschiedlichen URLs und unterschiedlichen Warteschlangen auf demselben Rechner zu haben?

Answer 1

Die Lösung für mich war die Installation von AppFabric für Windows Server v1.1 (ein Muss für jeden, der WAS/IIS gehostete WCF-Dienste oder WF-Anwendungen verwendet).

Damit wurde auch ein Problem behoben, bei dem der WAS-Prozess jedes Mal abstürzte, wenn ich eine Nicht-WCF-Warteschlange erstellte. Der Just-In-Time-Debugger hat dies ausgelöst:

 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: 

Ich schätze, dass nicht viele Leute WCF-/Nicht-WCF-Warteschlangen auf demselben Rechner mischen müssen. Ich hoffe, dies erspart jemandem den Schmerz, den ich in der letzten Woche durchgemacht habe!

Answer 2

Wie wäre es, einen anderen Anschluss zu verwenden? Sie können denselben Hostnamen verwenden und WAS anweisen, auf dem neuen Port in einem neuen vdir oder einer neuen Site zu aktivieren.

Answer 3

Leider verwendet der Listener den Namen des Dienstes, um festzustellen, auf welche Warteschlange er hören soll. Wenn Ihr Empfangsdienst also

MYOrganisation.Services.MyService.svc

Ihre Warteschlange sollte aufgerufen werden

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

Die Warteschlange wird also aufgerufen:

MYOrganisation.Services/MyService.svc

Probieren Sie das aus und melden Sie sich bei mir. Ich kann ein vollständiges Beispiel für eine funktionierende Konfiguration posten.

Mir kommt in den Sinn, dass Sie zwar nicht 2 verschiedene Endpunkte haben, aber denselben Dienst mit einem anderen Namensraum haben könnten (oder den Dienst einfach umbenennen), der auf eine andere Warteschlange hört. Nicht ideal, aber es ist das einzige, was ich gefunden habe, das funktionieren würde.

Answer 4

Der URI Ihres Dienst-Endpunkts muss (mehr oder weniger, siehe http://msdn.microsoft.com/en-us/library/ms789042.aspx ) den Namen der Warteschlange. Die Lösung wäre hier also, ein virtuelles Verzeichnis mit dem Namen staging zu erstellen und Ihren Dienst dort abzulegen.

Was die Bindungsinformationen angeht, verweist localhost auf den Server, auf dem der Warteschlangen-Listener lauschen soll. Wenn Ihre Warteschlangen also auf demselben Rechner wie IIS installiert sind, sollte dies tatsächlich localhost sein.

Answer 5

Auch ein interessanter Punkt: Der net.msmq listner adapter-Dienst scheint die Tatsache zu speichern, dass er nicht auf die Warteschlange zugreifen konnte. Wenn er versucht, auf eine Warteschlange für Ihren Dienst zuzugreifen, und dies fehlschlägt, und Sie dann die Berechtigung für den net.msmq Listener-Adapter hinzufügen, wird es immer noch nicht funktionieren. Ich habe den Dienst neu gestartet, und die Warteschlange wurde wieder überwacht.