7

私は、Websphere MQ キューにメッセージを投稿し、応答のために別のキューをポーリングする .NET Windows Forms アプリケーションを作成しています。応答が返された場合、アプリケーションはリアルタイムで応答を部分的に処理します。ただし、応答キューからも読み取る毎日のバッチ ジョブが残りの処理を実行できるように、応答はキューにとどまる必要があります。

メッセージを読むところまで来ました。私が理解できなかったのは、それを削除せずに読む方法です。

これが私がこれまでに得たものです。私は MQ の初心者なので、提案をいただければ幸いです。そして、C# で自由に応答してください。

Public Function GetMessage(ByVal msgID As String) As MQMessage
    Dim q = ConnectToResponseQueue()
    Dim msg As New MQMessage()
    Dim getOpts As New MQGetMessageOptions()
    Dim runThru = Now.AddMilliseconds(CInt(ConfigurationManager.AppSettings("responseTimeoutMS")))
    System.Threading.Thread.Sleep(1000) 'Wait for one second before checking for the first response'
    While True
        Try
            q.Get(msg, getOpts)
            Return msg
        Catch ex As MQException When ex.Reason = MQC.MQRC_NO_MSG_AVAILABLE
            If Now > runThru Then Throw ex
            System.Threading.Thread.Sleep(3000)
        Finally
            q.Close()
        End Try
    End While
    Return Nothing 'Should never reach here'
End Function

注:私のコードが実際にメッセージを削除することを確認していません。しかし、それが MQ が機能することを私が理解している方法であり、それが起こっていることのようです。それがデフォルトの動作でない場合は、修正してください。

4

5 に答える 5

14

MQOO_BROWSE オプションでキューを開く必要があります。次に、最初の読み取りで、MQGMO_BROWSE_FIRST オプションを使用して GET を実行します。最後に、後続の GET では MQGMO_BROWSE_NEXT オプションを使用する必要があります。

注: MQOO は MQ オープン オプションであり、MQGMO は MQ Get Message Options です。

于 2009-06-24T16:03:03.647 に答える
1

別々のキューでこれを行う必要があります。一日の終わりの処理には、独自のキューが必要です。メッセージの一部を処理した後、EOD キューに送信します。

[参照] オプションを使用すると、どこかで既に処理したメッセージを追跡する必要があります。

また、GET で待機タイムアウトを設定することもできます。したがって、「キューをチェックする前に1秒待つ」必要はありません。現在書かれているように、get message オプションで NOWAIT を設定していないため、no msg available 状態にヒットすることはありません。

于 2009-06-24T16:12:29.293 に答える
1

このディスカッションに参加するのが少し遅れたことに気づきました。おそらく、このアプリは既にコーディングされているでしょう。それを変更する必要がある場合、または同様のことを行う必要がある可能性のある他の人のために、いくつかの観察があります.

まず、v7 QMgr と v7 WMQ クライアントでこれを実行できる場合、これが推奨されるソリューションになります。v7 では、.Net サポートが SupportPac から基本製品の一部に移動されました。かなりの新機能、いくつかのバグ修正、およびパフォーマンスの向上があります。また、v7 では pub-sub を使用できます...これにより、2 つ目の観察が可能になります。

元の投稿の説明に基づいて、Pub-Sub でこれを行ったでしょう。メッセージを投稿するアプリは、投稿する必要があるのは 1 つだけで、トピックに投稿していることを知る必要さえありません。実際には、トピックにエイリアスを設定して、メッセージ プロデューサからキューのように見せることができます。次に、使用するアプリをサブスクライブするか、2 つの管理サブスクリプションを作成して、発行されたメッセージが指定した 2 つのキューに送られるようにすることができます。その後、アプリにはそれぞれ専用のキューがあり、プロデューサーとバッチ アプリにはコーディングの変更は必要ありません。構成だけです。もちろん、トランザクションを駆動するアプリは、メッセージを参照するのではなく、実際にメッセージを消費する必要があります。

ここでの利点はいくつかあります。

  • キューがメッセージでいっぱいになると、インデックス作成がディスクにフラッシュされ、しきい値を超えると、パフォーマンスが著しく低下する可能性があります。したがって、現在の方法はそれほど拡張性がありません。
  • pub-sub メソッドを使用すると、リアルタイム アプリまたはバッチ アプリのいずれかまたは両方の複数のインスタンスを持つことができ、これらは同じまたは異なる QMgr に配置できます。スケールアップは簡単です。
  • 同じ QMgr 上にある必要があるリアルタイム アプリとバッチ アプリの間の依存関係を排除します。
  • より透明な管理。リアルタイム キューにメッセージが蓄積されている場合は、問題があることがわかります。

ここにもいくつかのまったく異なる問題があります。これらの 1 つは、Fail if Quiescing オプションを使用することです。これの目的は、QMgr が正常にシャットダウンされたときに、このオプションによって API 呼び出しが、QMgr がシャットダウン中であることを示すリターン コードで終了するようにすることです。このオプションを含めない場合、2 つ以上の接続されたアプリで QMgr が決して実行しない可能性があります。クリーンにシャットダウンし、強制的にシャットダウンするか、そのプロセスを力ずくで強制終了する必要があります。原則として、Fail if Quiescing をサポートするすべての API 呼び出しで常に使用してください。それが存在する理由は、XA トランザクション性が必要であるが、何らかの理由でそれを使用できない人のためです。このシナリオでは、CONNECT および最初の GET または PUT 呼び出しで Fail if Quiescing set が使用され、後続の GET または PUT 操作では Fail が使用されません。これにより、QMgr は GET/PUT 呼び出しのセット全体が完了するまで待機しますが、その後、次の CONNECT または GET/PUT は Fail if Quiescing を使用するため、QMgr は必要に応じてシャットダウンする機会があります。

ここでのもう 1 つの観察事項は、ここのコードには Catch がないことです。コール スタックのさらに上のスコープに 1 つあると思いますか? 根本原因を追跡できるように、例外から WMQ 戻りコードを出力することを常にお勧めします。コンサルティング契約では、リターン コード (または JMS/XMS コードのリンクされた例外) を出力しないことは、アプリケーションの製品への昇格を妨げる重大な問題であるとクライアントに常にアドバイスしています。それは本当に重要です。getMessage() を呼び出すコードに問題があったとしても、ここにあるコード スニペットの例を再利用している人は、この重要な部分が欠けていることに気付かない可能性があります。

于 2010-05-07T06:31:45.813 に答える
-1

読み取り用:

AccessQueue オプション : MQOO_BROWSE および MQGetMessageOptions : MQGMO_BROWSE_NEXT

于 2022-02-07T13:02:32.250 に答える