以下のアドバイスを使用して、パブリッシュ/サブスクライブ アプリケーションを実行する際に生じる可能性のある共通問題の解決に役立ててください。
通常、応答は常にサブスクライバーに返されます。 ただしパブリッシャー側では、発信元のアプリケーションが認識されないまま、メッセージがパブリッシュされることがあります (例えば、入力ノードでデフォルトのトピック・プロパティーを使用することによって、または Compute ノードを使用して、このプロパティーをメッセージ・フローで変更することによって)。 そのメッセージの処理結果は、依然としてユーザー・トレースにログ記録されており、何が起きているかを知る手掛かりとなる場合があります。
サブスクライバーにメッセージが送信されるのは、それらがトピック、およびサブスクリプション・ポイント、およびフィルターと一致している場合のみです。 サブスクリプション・ポイントは、パブリケーション・メッセージ内ではなくメッセージ・フローで指定されるため、間違ったメッセージ・フロー設定によって予期しない障害が発生する可能性があります。
Publication ノードが含まれるフローのユーザー・トレースには、パブリケーションが何かと一致しているかどうかが表示されます。
複数の実行グループまたは複数のブローカーを使用している場合は、さらに複雑です。 応答は、メッセージがターゲット実行グループによって処理された後、サブスクライバーに送信されます。 他の実行グループ (およびブローカー) は非同期的に更新されます。 結果として、他の場所で作成されたパブリケーションを受け取るまでの遅延が生じる可能性があります。 ブローカーがビジーの場合、メッセージが完全に処理されるまでの遅延が生じる可能性があります。 複数ブローカーのセットアップで、通信が中断された場合、サブスクリプションの変更はブローカーのネットワークを介して伝搬されます。 チャネルをチェックします。
複数の実行グループまたはブローカーを使用した場合、負荷が大きいと、中間 WebSphere MQ キューを充てんすることができる場合があります。 この状態は、syslog に (ブローカーが、キューがいっぱいで書き込むことができない場合)、または WebSphere MQ ログに (チャネル経由で受け取るメッセージを、宛先キューがいっぱいで書き込むことができない場合) 報告されます。 このタイプのメッセージを参照するには、すべてのキュー・マネージャーでキュー項目数を表示して、ほぼいっぱいになっているキューがないかどうかをチェックします。
例えば、以下を使用する場合、
<Filter>Body.e_ALERT_BODY.eqnum<6</Filter>
以下を指定します。
<Filter>Body.e_ALERT_BODY.eqnum<6</Filter>
LIBPATH が設定されていない場合、JIT コンパイラーが正しくロードし実行するために、LIBPATH を設定しないでください。 ライブラリーを /var/wmqi/lib (AIX プロセス用のすべての WebSphere Message Broker に対して) または /usr/lib (システム上のすべてのプロセスに対して) にリンクすることによって、これを使用可能にできます。 AIX 構成用の WebSphere Message Broker は、DB2® ライブラリーに対してこのアクションを行います。
LIBPATH を設定する必要がある場合、 それを更新してディレクトリー /usr/java130/bin を組み込む必要があります。
LIBPATH=/usr/local/lib:/usr/java130/bin mqsistart mybroker