Begrenzung der Anzahl der JMS / MQ-Verbindungen, die von der OSB hergestellt werden

Es ist sehr einfach, JMS-Verbraucherdienste im Oracle Service Bus (früher bekannt als BEA AquaLogic Service Bus oder ALSB) zu erstellen, aber eines der Dinge, die Sie vielleicht kontrollieren möchten, ist die Anzahl der Verbindungen, die zur Abfrage eines JMS-Servers verwendet werden. In diesem Blog werden die Hintergründe zu JMS-Listenern in OSB beschrieben und wie Sie Probleme lösen können, wenn der JMS-Server mit Verbindungen überlastet ist. In diesem speziellen Fall handelt es sich bei dem JMS-Server um einen IBM Websphere MQ-Server, aber die meisten der Prinzipien gelten auch für andere JMS-Implementierungen. Der Hintergrund Wenn Sie einen Proxy-Dienst erstellen, der eine bestimmte Warteschlange abhört, dann werden Sie unter der Haube feststellen, dass OSB Message Driven Beans (MDBs) erstellt. Sie können dies selbst überprüfen: Wenn Sie in der Weblogic-Konsole unter Deployments nachsehen, sehen Sie, dass eine EAR-Datei bereitgestellt wurde, deren Name mit "ProxyService_" beginnt und die auch den Projektnamen (Ordnernamen in SBconsole) und den Namen Ihres Dienstes enthält. Diese EAR-Datei enthält die MDB, die durch Nachrichten ausgelöst wird, die in die Warteschlange gestellt werden, für die sie konfiguriert ist. Das sind alles großartige Standardfunktionen, und Sie können mit wenig Aufwand Ihre Dienste erstellen. Die Anpassung der Listener ist jedoch nicht so einfach (es sei denn, Sie wissen, wie das geht, und das werde ich Ihnen jetzt verraten :) ) In den meisten Produktionsumgebungen läuft OSB in einem Cluster mit mindestens 2 verwalteten Servern. Und pro verwaltetem Server gibt es standardmäßig 16 JMS-Verbindungen pro Polling MDB. Bei 1 Proxy-Dienst x 2 Servern x 16 Verbindungen erhalten Sie also automatisch 32 Verbindungen zu demselben MQ-Queuemanager. Ein MQ-Queuemanager ist standardmäßig so konfiguriert, dass maximal 100 Verbindungen gleichzeitig geöffnet sind. Das ist nicht viel, wenn Sie mich fragen, aber IBM hielt das für eine gute Wahl. Wenn Sie also 3 Proxy-Dienste haben, die alle verschiedene Warteschlangen auf demselben MQ-Queuemanager abhören, würde das bedeuten: 3 Proxy-Dienste x 2 Server x 16 Verbindungen = 96 Verbindungen. Fügen Sie noch ein paar Verbindungen durch andere Prozesse hinzu, die sich mit demselben Queuemanager verbinden (wie z.B. ein Geschäftsdienst, der Nachrichten in eine Warteschlange desselben Queuemanagers stellen möchte), und Sie erreichen sehr leicht die Zahl 100. Die Folge davon ist, dass MQ keine Verbindungen mehr annimmt (und sich aufzuhängen scheint) und Sie in seinen Protokolldateien "AMQ9513: Maximale Anzahl von Kanälen erreicht". Die Lösungen Es gibt zwei mögliche Lösungen für dieses Problem. Sie können entweder MQ oder OSB konfigurieren, um dieses Problem zu beheben: Lösen Sie das Problem auf der MQ-Seite: Sie könnten die Einstellungen MaxChannels und MaxActiveChannels in der Datei qm.ini von MQ erhöhen. Rechnen Sie wie oben beschrieben, fügen Sie einige Verbindungen für Nachrichtenproduzenten (z.B. Business Services; OSB öffnet auch für sie gerne mindestens 5 Verbindungen) und alle anderen Prozesse oder Benutzer hinzu, die Verbindungen zum Queuemanager öffnen dürfen. Lösen Sie das Problem auf der OSB-Seite: Um das Problem vom Service Bus aus zu lösen, sollten Sie die Größe Ihres EJB-Pools in Weblogic beschränken. Da es sich bei einer MDB um eine spezielle Art von EJB handelt, wird Ihre EAR-Datei, die die MDB enthält, einmal bereitgestellt, aber die darin enthaltene MDB wird 16 Mal im EJB-Pool erzeugt. Normalerweise kann man max-beans-in-free-pool und initial-beans-in-free-pool in der weblogic.xml verwenden, aber da OSB die EAR-Dateien für diesen Fluss automatisch generiert und bereitstellt, ist dies nicht möglich, ohne ein paar schmutzige Eingriffe vorzunehmen (und das werden wir nicht tun). Die eigentliche Lösung besteht darin, einen Workmanager mit einer Max-Thread-Beschränkung zu erstellen und diesem Workmanager die Dispatch-Richtlinie für Proxy-Dienste zuzuweisen. Rufen Sie die Weblogic-Konsole (/console) Ihrer OSB-Installation auf und klicken Sie unter Environment > Workmanagers auf die Schaltfläche New und erstellen Sie eine Maximum Threads Constraint. [caption id="attachment_3784" align="alignnone" width="403" caption="(WebLogic console, creating max threads constraints)"][/caption] Geben Sie ihm einen Namen und geben Sie im Feld Anzahl die maximale Anzahl von Threads (und damit Verbindungen) ein, die ein einzelner Proxy-Dienst / MDB in Anspruch nehmen darf. Richten Sie ihn auf den gesamten Cluster aus und erstellen Sie anschließend ein weiteres Element im Bildschirm Workmanagers. Wählen Sie diesmal einen Work Manager, geben Sie ihm einen Namen und weisen Sie ihn dem Cluster zu. Klicken Sie dann im Bildschirm Workmanagers auf den Namen des neu erstellten Work Managers und weisen Sie ihm die von Ihnen erstellte Maximum Thread Constraint zu. Ihr Workmanagers-Bildschirm enthält nun mindestens zwei neue Elemente (siehe Screenshot). Klicken Sie auf Speichern und aktivieren Sie Ihre Änderungen. [caption id="attachment_3786" align="alignnone" width="635" caption="(WebLogic console showing the workmanager overview)"][/caption] Gehen Sie danach in die Service Bus-Konsole (/sbconsole), suchen Sie Ihren Proxy-Dienst und bearbeiten Sie ihn. Auf der Seite JMS-Transportkonfiguration finden Sie ein Dropdown-Menü mit der Bezeichnung Dispatch Policy, das standardmäßig auf... nun ja... Standard eingestellt ist :)Ändern Sie dies und wählen Sie den Work Manager, den Sie gerade in der Weblogic-Konsole erstellt haben. Speichern Sie Ihren Dienst und Sie sind fertig. [caption id="attachment_3787" align="alignnone" width="562" caption="(OSB console, setting the dispatch policy)"][/caption] Fazit und Anmerkungen: Die beiden Lösungen haben nicht genau das gleiche Ergebnis. Entweder Sie sagen MQ, dass es mehr Verbindungen akzeptieren soll, oder Sie zwingen OSB, nicht so viele Verbindungen herzustellen. Für welche Lösung Sie sich entscheiden, hängt von vielen verschiedenen Dingen ab, wie z.B. dem erforderlichen Nachrichtendurchsatz und den Netzwerkrichtlinien, so dass ich darauf keine kurze Antwort geben kann. Eine letzte Bemerkung zu den Verbindungen: Da diese MDBs die Verbindung mit dem JMS-Server ständig offen halten, sollten Sie vorsichtig sein, wie Sie Ihre OSB-Domäne beenden. Vor allem in der Entwicklungsphase könnte es verlockend sein, die Domäne zwangsweise herunterzufahren, um Zeit zu sparen. Ich habe jedoch mehrfach erlebt, dass dies dazu führt, dass die Verbindungen auf der MQ-Seite nicht richtig geschlossen werden. Als beste Vorgehensweise sollten Sie daher das normale Shutdown-Verfahren verwenden und während Sie warten, lesen Sie unseren Blog :)