2017-03-16 3 views
1

Wenn ein .net Windows-Dienst mit der Websphere MQ-Warteschlange für die Subskription verbunden ist und Nachrichten weiterliest, wie können wir mit Problemen wie der Netzwerktrennung umgehen oder etwas Falsches passiert ist, können wir uns ständig auf die Eigenschaft MQQueueManager.IsConnected verlassen? Dieser Artikel ist verwirrend ich: IC75673: MQQueueManager.IsConnected property is "true" after the connection is broken in a .NET application.Wie behandelt man Verbindungsfehler für die Subskription in WebSphere Queue?

Unten ist der Code Ich habe Nachrichten aus der Warteschlange zu lesen und ich bin mit MQ Version 8,0

private MQQueueManager _queueManager; 
private MQQueue _queue; 
private MQTopic _topic; 
public bool isSubscribed = false; 

public void Subscribe() 
{ 
    var queueManagerName = "myQueueManager"; 
    var properties = new Hashtable(); 
    //Set all the properties here 
    _queueManager = new MQQueueManager(queueManagerName, properties); 

    //Conect to Queue 
    _queue = _queueManager.AccessQueue("devQueue", MQC.MQOO_INPUT_AS_Q_DEF); 

    isSubscribed = true; 
    while (isSubscribed) 
    { 
     if (cancellationToken.IsCancellationRequested) 
     { 
      isSubscribed = false; 
      cancellationToken.ThrowIfCancellationRequested(); 
     } 
     try 
     { 
      Receive(onMessageReceived); 
     } 
     catch (Exception ex) 
     { 
      Console.WriteLine("Exception: {0}", ex); 
     } 
    } 
} 


public override void Receive<T>(Action<T> onMessageReceived) 
{ 
    try 
    { 
     var dataReceived = new MQMessage(); 
     _queue.Get(dataReceived); 

     T message; 
     message = (T)(object)dataReceived; 

     onMessageReceived(message);  
     _queueManager.Commit(); 
    } 
    catch (Exception ex) 
    { 
     throw ex; 
    } 
} 

Antwort

0

APAR IC75673, die Sie verknüpft wurde in einer Version 7.0 behoben. 1.6 von MQ, die Aug 01 2011 freigegeben wurde. MQ v8.0 wurde veröffentlicht June 13 2014. Im Allgemeinen werden alle in einer früheren Version von MQ behobenen Fehler auch in einer neuen Version behoben.

Stellt Ihre Anwendung eine Verbindung zu einem Warteschlangenmanager auf demselben Windows-Server her, auf dem die Anwendung ausgeführt wird? In Ihrem Code geben Sie keine Angaben wie Hostname, Port, Kanalname usw. an, die anzeigen würden, dass Sie eine MQ Client-Verbindung über das Netzwerk verwenden. Es ist möglich, dass Sie die Umgebungsvariablen MQSERVER oder MQCHLLIB/MQCHLTAB verwenden, um die Konnektivitätsdetails bereitzustellen.

Wenn Ihre App eine lokale Verbindung zum Warteschlangenmanager herstellt, verwendet sie den so genannten Bindungsmodus und ist nicht auf das Netzwerk angewiesen. Die IsConnected-Methode ist ein gutes Zeichen dafür, dass Sie immer noch verbunden sind. Die Dokumentation besagt, dass, wenn Ihre Verbindung im Leerlauf ist, der angegebene Status der letzte bekannte Status ist, als die letzte Aktivität ausgeführt wurde (Get, Put, etc).

Wenn Ihre App eine MQ-Clientverbindung über das Netzwerk herstellt, hängt die Zeit, die der Client benötigt, um eine unterbrochene Verbindung zu erkennen, vom HBINT ab, der zwischen dem Warteschlangenmanager und dem MQ-Client ausgehandelt wird. Für .NET scheint es, dass Sie eine MQ-Kanaltabelle verwenden müssen, um diesen Wert festzulegen. @Morag Hughson Antwort auf StackOverflow Frage "WebSphere MQ - Changing channel definition structure using XMS.NET API" bietet einige weitere Details. Sie können sich auch meine Antwort auf die StackOverflow-Frage "Setting timeout for IBM MQ" ansehen, um mehr darüber zu erfahren, wie sich der HBINT auf das TIMEOUT eines Kundenkanals auswirkt.

Verwandte Themen