2016-11-22 5 views
0

現在のアプリケーション・ロジックは、 'PROCESS' WMQキューの深さを使用して、ジョブがIIB9ワークフローによって処理されているかどうかを判断します。ワークフローがメッセージを処理している場合、アプリケーションはそのワークフローが終了するまで待機します。ワークフローが終了すると、「PROCESS」キューはGET操作を使用して空になり、アプリケーションは処理のためにシーケンス内に他のメッセージを送信します。私は、ワークフローによって並列に処理される複数のメッセージを区別するために、JMSセレクタを使用しています。JMS APIはメッセージをブラウズできません.IBM APIは

問題は、キューの深さを判断することです。 JMS APIは深さを0にしていますが、IBM APIは深度を1(期待どおり)にしています。残念ながら、いくつかの複雑なメッセージセレクタを使用してロジックとしてIBM APIを使用することはできません。

誰もこの奇妙な行動を見ましたか?サイズチェックが行われている間は、IIB9ワークフローが進行中であることに注意してください。微調整する設定はありますか?

JMSコード(メッセージセレクタを明確にするため取り除か):

public class QDepthJMS { 

public static void main(String[] a) throws Exception { 
    MQConnectionFactory factory = new MQConnectionFactory(); 
    factory.setTransportType(WMQConstants.WMQ_CM_CLIENT); 
    factory.setQueueManager("QM01"); 
    factory.setHostName("10.10.98.15"); 
    factory.setPort(1414); 
    factory.setChannel("Java.Clients"); 

    MQConnection connection = (MQConnection) factory.createConnection(); 
    connection.start(); 

    MQSession session = (MQSession) connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 

    MQQueue queue = (MQQueue) session.createQueue("queue:///PROCESS"); 
    MQQueueBrowser browser = (MQQueueBrowser) session.createBrowser(queue); 

    Enumeration<Message> msgs = browser.getEnumeration(); 
    int count =0; 
    if (msgs.hasMoreElements()) { 
     msgs.nextElement(); 
     ++count; 
    } 

    System.out.println(count); 
} 
} 

IBMのAPI(Check MQ queue depth):

public class QDepth { 

private final String host; 
private final int port; 
private final String channel; 
private final String manager; 
private final MQQueueManager qmgr; 

public QDepth(String host, int port, String channel, String manager) throws MQException { 
    this.host = host; 
    this.port = port; 
    this.channel = channel; 
    this.manager = manager; 
    this.qmgr = createQueueManager(); 
} 

public int depthOf(String queueName) throws MQException { 
    MQQueue queue = qmgr.accessQueue(queueName, MQC.MQOO_INQUIRE | MQC.MQOO_INPUT_AS_Q_DEF, null, null, null); 
    return queue.getCurrentDepth(); 
} 

@SuppressWarnings("unchecked") 
private MQQueueManager createQueueManager() throws MQException { 
    MQEnvironment.channel = channel; 
    MQEnvironment.port = port; 
    MQEnvironment.hostname = host; 
    MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES); 
    return new MQQueueManager(manager); 
} 

public static void main(String[] a) throws Exception { 
    QDepth qd = new QDepth("10.10.98.15, 1414, "Java.Clients", "QM01"); 
    System.out.println(qd.depthOf("PROCESS")); 
} 
} 

答えて

2

あなたが "等と同様に、" 比較されていない - IBMのAPIは、キューを照会つまり、キュー内のメッセージの数ですが、JMS APIはメッセージを参照してカウントしています。誰かが作業単位(シンクポイント)の下にメッセージを入れてコミットしていないというのが通常の原因です。そのため、IBM APIを実行する時点で、 1メッセージがキューにあります(...ありますが、まだコミットされていないためgettable/browseableではありません)。

あなたはRUNMQSC DIS QSTATUSすることにより、この使用RUNMQSC(そしておそらくGUI)を確認し、UNCOM属性を見ることができます - ジェイソンの返信に追加http://www-01.ibm.com/support/docview.wss?uid=swg21636775

+0

を参照してください:JMS 1.1仕様では、キューの深さを決定するための任意のAPIを記述していません。だからそれは奇妙ではありません。 – Shashi

+0

@ JasonE、あなたの提案は確かに問題を解決しました。私はトランザクション(UOW)のコンテキストにあったため、メッセージをブラウズすることができませんでした。私はIIB9ワークフローでトランザクションモードを無効にしており、この問題は修正されています。 – Sandeep

関連する問題