WCF Remote MSMQ - Ich kann in eine entfernte Warteschlange schreiben, aber nicht empfangen

Question

JobsServer: Windows Server 2008 R2 .NET Version: 4.5

Ich verwende WCF, um zwei Server zu verbinden - app y Warteschlange . Ich möchte app um Nachrichten senden/empfangen zu können von Warteschlange . Aus irgendeinem Grund kann die App Nachrichten senden, aber NICHT empfangen.

Die netMsmq-Bindung sieht wie folgt aus:

<binding name="JobExecutionerBinding" receiveErrorHandling="Move">
  <security>
    <transport msmqAuthenticationMode="None" msmqProtectionLevel="None" />
  </security>
</binding>

Und die Dienstbindung

Jetzt sieht die Client-Bindung wie folgt aus:

<endpoint   address="net.msmq://queue/private/jobs" 
            binding="netMsmqBinding" 
            bindingConfiguration="JobExecutionerBinding" 
            contract="JobExecution.Common.IJobExecutionService" 
            name="SimpleEmailService" 
            kind="" 
            endpointConfiguration=""/>

Zur Sicherheit habe ich ein paar Namen geändert.

Der WC-Client kann also ohne Probleme an die entfernte Warteschlange senden. Er stellt die ausgehende Nachricht sogar ordnungsgemäß in eine Warteschlange und leitet sie später weiter, falls der Server der entfernten Warteschlange ausfällt. Aber jedes Mal, wenn ich den WCF-Dienst starte, erhalte ich diese Meldung:

Es ist ein Fehler beim Öffnen der Warteschlange aufgetreten. Stellen Sie sicher, dass MSMQ installiert ist installiert ist und läuft, die Warteschlange existiert und eine entsprechende Berechtigung zum Lesen hat. Die innere Ausnahme kann zusätzliche Informationen enthalten. ---> System.ServiceModel.MsmqException: Beim Öffnen der Warteschlange ist ein Fehler aufgetreten Warteschlange: Die Warteschlange existiert nicht oder Sie haben nicht genügend Berechtigungen, um den Vorgang durchzuführen. (-1072824317, 0xc00e0003). [ ] Nachricht kann nicht von der Warteschlange gesendet oder empfangen werden. Stellen Sie sicher, dass MSMQ installiert ist und läuft. Stellen Sie außerdem sicher, dass die Warteschlange zum Öffnen verfügbar ist mit dem erforderlichen Zugriffsmodus und der erforderlichen Berechtigung. unter System.ServiceModel.Channels.MsmqQueue.OpenQueue() bei System.ServiceModel.Channels.MsmqQueue.GetHandle() bei System.ServiceModel.Channels.MsmqQueue.SupportsAccessMode(String formatName, Int32 accessType, MsmqException& msmqException) --- Ende der inneren Ausnahme-Stacktrace --- bei System.ServiceModel.Channels.MsmqVerifier.VerifyReceiver(MsmqReceiveParameters receiveParameters, Uri listenUri) bei System.ServiceModel.Channels.MsmqTransportBindingElement.BuildChannelListener[TChannel](BindingContext context) at System.ServiceModel.Channels.Binding.BuildChannelListener[TChannel](Uri listenUriBaseAddress, String listenUriRelativeAddress, ListenUriMode listenUriMode, BindingParameterCollection parameters) at System.ServiceModel.Description.DispatcherBuilder.MaybeCreateListener(Boolean actualCreate, Type[] supportedChannels, Binding binding, BindingParameterCollection parameters, Uri listenUriBaseAddress, String listenUriRelativeAddress, ListenUriMode listenUriMode, ServiceThrottle throttle, IChannelListener& result, Boolean supportContextSession) bei System.ServiceModel.Description.DispatcherBuilder.BuildChannelListener(StuffPerListenUriInfo stuff, ServiceHostBase serviceHost, Uri listenUri, ListenUriMode listenUriMode, Boolean supportContextSession, IChannelListener& result) bei System.ServiceModel.Description.DispatcherBuilder.InitializeServiceHost(ServiceDescription description, ServiceHostBase serviceHost) bei System.ServiceModel.ServiceHostBase.InitializeRuntime() at

Ich bin seit 8 Stunden überall auf StackOverflow und im Internet unterwegs. Hier ist, was ich getan habe:

• Sicherstellen, dass ANONYMOUS LOGIN, Everyone, Network, Network Service und Local Service volle Kontrolle haben
• Ich habe den entfernten MSMQ-Server gestoppt und beobachtet, was der WCF-Dienst tut, und ich erhalte eine andere Fehlermeldung - ich bin also sicher, dass der WCF-Dienst beim Starten mit dem MSMQ-Server spricht
• Deaktivieren Sie die Windows-Firewall auf beiden Rechnern und öffnen Sie alle Ports über EC2-Sicherheitsgruppen.
• Setzen Sie AllowNonauthenticatedRpc und NewRemoteReadServerAllowNoneSecurityClient in der Registrierung auf 1
• MS DTC auf beiden Servern konfiguriert (die Warteschlange ist transaktional, aber ich erhalte die gleiche Fehlermeldung unabhängig davon, ob die Warteschlange transaktional ist oder nicht)
• Bestätigt, dass der WCF-Server startet gut, wenn ich die lokale Warteschlange verwenden, und empfängt ohne ein Problem

Hilfe!!! Ich kann meine Anwendung ohne eine Remote-Queueing-Lösung nicht skalieren.

Answer 1

Das geht aus Ihrem Beitrag nicht hervor die Ebene kann nicht lesen und, was noch wichtiger ist welche Warteschlange .

Das transaktionale Lesen entfernter Warteschlangen wird jedoch nicht unterstützt:

Message Queuing unterstützt Senden Transaktionsnachrichten an entfernte Warteschlangen, unterstützt aber nicht das Lesen von Nachrichten aus einer entfernten Warteschlange innerhalb einer Transaktion . Dies bedeutet, dass ein zuverlässiger, genau einmaliger Empfang von entfernten Warteschlangen nicht möglich ist. 見る Lesen von Nachrichten aus entfernten Warteschlangen

Ich vermute, dass Ihr System irgendwo noch transaktionale Remote-Lesevorgänge durchführt, obwohl Sie erwähnt haben, dass Sie diese deaktiviert haben.

Vom Standpunkt der besten Praxis aus betrachtet, wird Ihr Entwurf, selbst wenn er funktioniert, nicht skalierbar sein, was schade ist, da Sie ja erwähnt haben, dass Sie das wollen.

Die Fernauslesung ist ein aufwändiges und daher ineffizientes Verfahren. Die Einbeziehung von Fernlesevorgängen in eine Anwendung schränkt die Skalierung ein. 1

Sie sollten immer Fernschreiben no entfernt lesen.

Eine bessere Möglichkeit ist das Einfügen einer Nachrichtenmakler o Router-Dienst die als zentraler Punkt für die Nachrichtenübermittlung dient. Ihr app y Warteschlange Dienste (verwirrende Namen übrigens) sollten lediglich transaktional aus ihren lokalen Warteschlangen lesen .

d.h.

• app transaktional lesen sollte, ist lokale Warteschlange
• app transaktional an die Gegenstelle senden sollte Makler
• Makler liest transaktional die lokale Warteschlange
• Makler sendet transaktional an entfernte Warteschlange

Ähnlich verhält es sich, wenn Ihr Warteschlange Tier wollte antworten, dass der umgekehrte Prozess wie oben beschrieben ablaufen würde.

Wenn Sie später die Leistung verbessern möchten, können Sie eine Dynamischer Router die eine Nachricht auf der Grundlage dynamischer Regeln oder Umgebungsbedingungen wie z. B. Stresslevel an eine andere Remote-Warteschlange auf einem anderen Rechner weiterleitet.

Answer 2

Entfernte transaktionale Lesevorgänge werden ab MSMQ 4.0 (Windows Server 2008) unterstützt. Wenn Sie mit diesem Problem konfrontiert sind, sollten Sie Folgendes überprüfen https://msdn.microsoft.com/en-us/library/ms700128(v=vs.85).aspx