Wie bekomme ich den Websphere MQ Verbindungsstatus und wie stelle ich die Verbindung zurück?

8

1.) Wie prüfe ich von einem .net Client, ob der Client mit dem Server verbunden ist (dh senden und empfangen kann). Ja, ich könnte eine Nachricht in einem try-Block senden und die folgende Ausnahme abfangen. Ich hoffe auf eine elegantere Lösung.

2) Wie öffne, schließe und öffne ich wieder Verbindungen? Bei meinen Versuchen, die obige Frage 1 zu lösen, habe ich festgestellt, dass, wenn ich eine Verbindung öffne, connection.Close () aufgerufen wird. Ich kann keine weitere Verbindung von der Verbindungsfactory erhalten (siehe Codefragment unten). Ich erhalte die Fehlermeldung XMSCC0008

Ich verwende eine sehr standardmäßige Vanilla MQ-Konfiguration. Hier ist, wie mein Client verbindet:

%Vor%

Dabei ist MQAccess eine kleine Dienstprogrammklasse.

Die Frage zum Hinzufügen von MQAccess-Code wurde bearbeitet:

%Vor%

Bearbeiten: Die MQAccess-Klasse in MQClient umbenannt. Es wurde eine Instanzklasse pro T Rob-Vorschlag erstellt. Disconnect-Methode stürzt weiterhin mit den oben aufgeführten Fehlermeldungsnachrichten ab

%Vor%     
Sam 18.10.2012, 17:30
quelle

2 Antworten

8

Das Problem ist hier - & gt; where MQAccess is a small utility class.

Im ersten Teil der Frage wird gefragt, wie Sie feststellen können, ob die Verbindung aktiv ist. Die XMS-Klassen für WebSphere MQ sind eine Implementierung der JMS-Spezifikation für Nicht-Java-Plattformen. Sie folgen der JMS-Spezifikation ziemlich genau, und die JMS-Spezifikation hat keine Methode für die Verbindung oder Sitzung, die äquivalent zu isConnected ist, daher auch XMS nicht. Alle GET- und PUT-Aktivitäten sollten jedoch in einem try / catch-Block ausgeführt werden, um die JMS-Ausnahmen abzufangen. (Von dem Sie immer drucken linkedException , richtig?) Wenn eine JMS-Ausnahme geworfen wird, behandelt die App es entweder als fatal und stirbt oder es schließt alle JMS-Objekte mit Ausnahme der Connection Factory, wartet ein paar Sekunden und fährt dann die Verbindungssequenz erneut.

UPDATE basierend auf neuen Informationen in der Frage:
Vielen Dank, dass Sie die MQAccess-Klasse veröffentlicht haben. Dies bietet einen beträchtlichen Einblick in das, was passiert, obwohl es immer noch keinen Code gibt, der zeigt, wo die Verbindung geschlossen und wie in Teil 2 der Frage wieder geöffnet wird.

Der Code zeigt jedoch, dass die Klasse MQAccess eine private Instanz von ICONNECTION connection erstellt, wenn die Klasseninstanz erstellt wird, die dann öffentlich als MQAccess.GetConnection verfügbar gemacht wird. Die MQAccess -Klasse, wie sie aktuell gepostet wird, hat keine öffentliche oder private Klassenmethode, die das Verbindungs-Handle von connection ersetzen würde. Wenn MQAccess.Connection.Close() also jemals aufgerufen wird, wird diese IConnection -Objekt-Instanz innerhalb der MQAccess -Klasse für immer beibehalten nach einem ungültigen Verbindungshandle. Sobald die Verbindung geschlossen ist, ist diese Instanz von MQAccess effektiv tot. Sie müssten MQAccess löschen und neu starten, um eine neue Verbindung zu erhalten.

Die Klasse MQAccess stellt die Verbindungsfactory öffentlich zur Verfügung. Theoretisch wäre es also möglich, MQAccess.GetConnection von außerhalb der Klasse aufzurufen und ein gültiges neues IConnection -Objekt zu erhalten, selbst nachdem das ursprüngliche geschlossen wurde. Diese Instanz würde jedoch außerhalb des Geltungsbereichs der Klasse MQAccess liegen. Daher würden sich nachfolgende Aufrufe von MQAccess auf die nicht mehr vorhandene Instanzvariable connection und nicht auf die außerhalb der Klasse erstellte neue Verbindungsinstanz beziehen.

Wenn Sie Verbindungen schließen und neu erstellen müssen, können Sie dies von innerhalb von MQAccess aus verwalten. Ein Low-Tech-Ansatz könnte sein, eine MQAccess.Close() -Methode für die Verbindung zu schreiben, die die bestehende Verbindung schließen würde, und sofort connection = GetConnection(); aufrufen, so dass die private connection -Variable immer ein gültiges Verbindungs-Handle enthält.

Wenn das Problem dadurch nicht behoben wird, senden Sie den Code, der die Verbindung schließt und erneut erstellt,

Die nicht-transaktionierte Sitzung über eine Netzwerkverbindung öffnet übrigens die Möglichkeit, Nachrichten für jeden JMS-Provider, einschließlich WMQ, zu verlieren oder zu duplizieren. War das was du beabsichtigst? Ich habe erklärt, warum dies in einem anderen SO-Post ist hier .

    
T.Rob 19.10.2012, 02:50
quelle
5

Hinzufügen zu Kommentaren von T.Rob.

Frage 1:
Ich hoffe, Sie haben Zugriff auf den Quellcode von MQAccess . Wenn ja, könnten Sie eine Eigenschaft in MQAccess anzeigen, die angibt, ob eine Verbindung aktiv ist oder nicht. Wenn Sie keinen Zugriff haben, müssen Sie möglicherweise den Autor dieser Klasse bitten, diese Eigenschaft hinzuzufügen. Zum Festlegen / Zurücksetzen der Eigenschaft können Sie Folgendes tun.

1) Legen Sie die Eigenschaft fest, nachdem die Methode createConnection erfolgreich zurückgegeben wurde.
2) Legen Sie einen Ausnahme-Listener für die Verbindung fest.
3) Setzen Sie die Eigenschaft im Exception-Handler zurück. Überprüfen Sie den Ursachencode, und setzen Sie die Eigenschaft zurück, wenn es sich um einen Verbindungsfehler handelt (XMSWMQ1107 und die verknüpfte Ausnahme können MQRC 2009 aufweisen).

Frage 2
Es würde helfen, wenn Sie uns zeigen können, wie Sie closing und reopening Verbindungen sind. Meine Empfehlung, die Verbindung zu schließen, ist:
1) Zuerst eine Verbindung.Stoppen ().
2) Entfernen Sie alle Nachrichtenlistener, tun Sie grundsätzlich einen consumer.MessageListener = null.
3) Dann mach connection.Close ().
4) Machen Sie eine Verbindung = null

Zusätzliche Informationen Hier ist die Probe, die ich zum Testen verwendet habe.

%Vor%

Legen Sie in der Methode, in der die Verbindung erstellt wird, den Ausnahme-Listener fest.

%Vor%

Immer wenn ein Verbindungsfehler auftritt, wird der Ausnahme-Listener aufgerufen und das Flag wird auf true gesetzt.

Es empfiehlt sich, die Objekte zu entsorgen, wenn sie nicht mehr benötigt werden. Es gibt eine Eltern-Kind-Beziehung, Consumer, Producer usw. sind Kinder von Session, die wiederum ein Kind von Connection ist. So Reihenfolge der Verfügung kann Kind zuerst und Elternteil nächstes sein. Wenn jedoch ein Elternteil entsorgt wird, werden auch Kinder automatisch entsorgt.

    
Shashi 19.10.2012 04:27
quelle

Tags und Links