2017-12-11 23 views
6

私のアプリケーションでは、HornetQ 2.4.1がメッセージジャーナルファイル(時には何千ものファイル)を積み重ねていることに気がつきました。私はJMSキュー経由でHornetQを使用しています。ワイルドフライ8.2。通常、サーバーインスタンスを起動するとき、HornetQには3つのメッセージングジャーナルとロックファイルがあります。HornetQ永続性がファイルを削除していない

HQ221014: 54% loaded

をファイル、うまくサーバーの負荷を削除する場合:メッセージ・ジャーナル・ファイルの積み上げ

は、サーバーを再起動したときに、私たちは述べてログを参照してくださいよな問題を引き起こしました。私はいくつか実験しましたが、これらのファイルのメッセージはすでに処理されているように見えますが、時間がたつにつれてそれらが何度も積み重なり続けるのはわかりません。

編集1:メッセージを承認していないことを示すthis linkが見つかりました。しかし、私たちがconnection.createSession(false,Session.AUTO_ACKNOWLEDGE);のようなセッションを作成するとき。

私は解決策を探し続けます。

+1

あなたはXAトランザクションまたはJMSトランザクションを使用していますか?そして、あなたのリソースアダプタをstandalone.xmlでどのように定義しますか? – user2612030

+0

私はXAトランザクションを使用しています。私はリソースアダプタに関する情報を少し得るつもりです。 – dimwittedanimal

+1

XAトランザクションを使用している場合は、上記セッションで何をしても問題ありません。メッセージは、XAトランザクションがコミットされたときに肯定応答される必要があります。私はHornetQについては知らないが、一般的には、これは多くの製品が少しばかりバギーであるエリアである。 – user2612030

答えて

0

afterDelivery()メソッドの呼び出しが失敗したために、これが原因で発生していることが判明しました(私は現在、サーバーの負荷やネットワークのハングアップと関係していると考えています)。私はそのキューに頻繁に当たらないことでこれに対処しています。エレガントではありませんが、私の目的に役立ちます。

ログに私が見つけたHornetQのメッセージを、以下を参照してください。

HQ152006: Unable to call after delivery 
javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:87) 

HQ222144: Queue could not finish waiting executors. Try increasing the thread pool size 

HQ222172: Queue jms.queue.myQueue was busy for more than 10,000 milliseconds. There are possibly consumers hanging on a network operation 
関連する問題