2017-01-04 4 views
0

メッセージを処理するためにSpringのamqp MessageListener実装を使用しています。 Beanの定義と実際の例は次のとおりです。再試行のためにメッセージをキューに保持して正常に処理するまで

public class AutomationMessageListenerServiceImpl implements MessageListener { 

public void onMessage(Message message) { 
     EntityMessage message= null; 
     try { 
      message= jsonDeserializer.covertPayload(message.getBody()); 
      dispatchToHandler(message); 
     } catch (Exception e) { 
      e.printStackTrace(); 
     } 
    } 
} 





<rabbit:listener-container connection-factory="rabbitConnectionFactory"> 
     <rabbit:listener queue-names="${listen.queue}" ref="messageListener"/> 
    </rabbit:listener-container> 

    <bean id="messageListener" class="com.tcl.gvg.itsm.automation.core.messaging.AutomationMessageListenerServiceImpl"/> 

ここでの問題は、キャッチブロックのすべてのエラーを処理しているため、キューはメッセージを正常に処理したと思っています。しかし、私は例外をスローすることはできません。なぜなら、親インタフェースが問題を引き起こすからです。

多くのコード変更を自分で行うことなくこれを行う方法はありますか?

+0

私は不正な形式のJSONを送信する場合、管理者が行動を取るが、それはのonMessage()契約方式のdoesntを持っている上記のコード –

答えて

0

RuntimeExceptionで例外をラップして呼び出し側にスローしました。例えば

catch (Exception e) { 
      throw new RuntimeException(e); 
} 
1

それは親の方法が問題

コンテナはonMessage()を呼び出して、あなたの他のコードが関与していない原因になりますので、あなたが

によって何を意味するかは明らかではありません。いずれにしても、再キューしてもすぐにメッセージが再配信されます。

JSONのような致命的なエラーの場合は、デッドレターの交換/キューを設定し、メッセージをAmqpRejectAndDontRequeueExceptionに送信してください。

または、RabbitTemplateを使用して、不良メッセージをDLQに送信します。

+0

MessageListenerインタフェースを持つ場合ではありませんまで、メッセージはキューに保持されている必要があります例外をスローする。だから、私はRuntimeExceptionをスローして、メッセージが承認されないようにしなければならなかった。 –

+0

それは正しい。 –

関連する問題