Announcement Announcement Module
No announcement yet.
RedeliveryPolicy not working in case of ws:outbound-gateway encounters IOException Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • RedeliveryPolicy not working in case of ws:outbound-gateway encounters IOException


    I am trying to develop an application where I have a jms:message-driven-channel-adapter, which listens to a queue. After receiving the message I pass it through following stages
    1. Transformation of the received message
    2. Unmarshalling the in-message,
    3. Filter the unmarshelled message.
    In case the filter returns true, I create some webservice request and send the webservice request.
    Now if the webservice is down, I get n. What I want to achive in above case is that the transaction should be rolled back and ten message should be redelivered as configured in AMQ'a RedeliveryPolicy.
    When I explicitly throw RuntimeException at 1 and 3 mentioned above, I can see that the redelivery policy worked and the message is sent to ActiveMQ.DLQ. However when I get IOException, the redelivery doesn't work. I can only see that in the log the it hasn't tried for preconfigured number of times.
    When I looked at the console of AMQ, I found that it shown Connection reset in case I get IOException. I don't understand why the message is displayed on AMQ.

    I have configured transaction-manager in message-driven-channel-adapter.
    Below are some imp. configs

    <jms:message-driven-channel-adapter id="jsmin"

    <beans:bean id="myTxManager" class="org.springframework.jms.connection.JmsTrans actionManager">
    <beansroperty name="connectionFactory" ref="connectionFactory"></beansroperty>

    Please provide inputs on this.

    Thanks in advance.
    Last edited by dropofspring; May 29th, 2013, 09:22 AM. Reason: Added configs for more reference.

  • #2
    You don't need a transaction manager in this case; you can just use local transactions on the session.

    It shouldn't make a difference though.

    I suggest you turn on DEBUG logging and compare the results between the different exception types.