3

AIXサーバーの下でOC4Jにデプロイされた単純なJMSアプリケーションがあります。私のアプリケーションでは、AS400サーバーの下にデプロイされたWebsphere MQ上のいくつかのキューをリッスンし、他のキューに送信しています。

問題は、これらのキューへの接続がエラーでしばらくアイドル状態になっているときに終了/閉じられることMQJMS1016 です（これは問題ではありません）。その場合、接続を回復しようとしますが、古い接続は機能しますMQでスタックし、手動で終了するまで終了しません。

リカバリコードは次のようになります。

public void recover() {
    cleanup();
    init();
}

public void cleanup(){
    if (session != null) {
        try {
            session .close();
        } catch (JMSException e) {
        }
    }
    if (connection != null) {
        try {
            connection.close();
        } catch (JMSException e) {
        }
    }
}

public void init(){
    // typical initialization of the connection, session and queue...
}
4

2 に答える 2

3

MQJMS1016は内部エラーであり、接続が失われたのはコードまたはWMQ自体に問題があるためであることを示しています。チャネルを調整することは役に立ちますが、アプリが孤立した接続を、利用可能なすべてのチャネルを使い果たすのに十分な速さで吐き出す理由の問題に取り組む必要があります。

私が最初にやりたいことは、実行中のWMQとWMQクライアントのバージョンを確認することです。これが新規開発の場合は、2011年9月にv6が終了したため、WMQ v7クライアントを使用していることを確認してください。v7クライアントは、アップグレードできるようになるまでv6QMgrで動作します。v7クライアントとQMgrに到達すると、かなりの数のチャネル調整と再接続のオプションを利用できるようになります。

WMQ v7クライアントのダウンロードはこちらです：http：//bit.ly/bXM0q3

また、上記のコードの再接続ロジックは、試行の合間にスリープしないことに注意してください。クライアントが高速で接続要求をスローすると、WMQリスナーが過負荷になり、非常に効果的なDOS攻撃が実行される可能性があります。試行の合間に数秒間スリープすることをお勧めします。

最後に、リンクされた例外をJMSExceptionキャッチブロックに出力してください。JMSトランスポートプロバイダーに問題がある場合、JMSリンク例外には低レベルのエラー情報が含まれます。WMQの場合、2035MQRC_AUTHORIZATION_ERRORまたは2033MQRC_NO_MSG_AVAILABLEなどの理由コードが含まれています。次に例を示します。

try {
  .
  . code that might throw a JMSException
  .
} catch (JMSException je) {
  System.err.println("caught "+je);
  Exception e = je.getLinkedException();
  if (e != null) {
    System.err.println("linked exception: "+e);
  } else {
    System.err.println("No linked exception found.");
  }
}

ある夜の午前2時にエラーが発生した場合、WMQ管理者はリンクされた例外について感謝します。

于 2010-04-26T21:00:33.967 に答える
1

孤立した接続（MQ側でスタックした接続）はメッセージ処理に影響を与えない（つまり、メッセージを消費しない）ため、MQで許可されている最大接続に達するまでそのままにしておきます。

リカバリーは機能しなくなり、その時点に達すると、MQ管理者は孤立した接続を手動でクリーンアップする必要がありましたが、この特定の問題を検索すると、IBMサポート・サイトで報告された問題が発生しました。

こちらをチェック

于 2010-01-17T11:18:32.633 に答える