FAQ
Hello,

I want to setup 2 separate routes in my camel context to create a
synchronous spring bean method, which triggers a JMS based request-reply
service.

The front (synchronous) bean is invoked via a simple Spring web MVC
controller, and dumps the response back to the browser. The second route, in
a separate transaction, pulls the message from the request queue, performs a
simple transformation and puts the response back into (shared) response
queue (both queues from external IBM MQ server).

At first, things were looking fine, because my browser page renders the
response as expected. But in a second look, I discovered that the log still
mentions a timeout (default 20 secs) waiting for the reply, although the
reply has been received already! And secondly, after the timeout, the
response message (re-) occurs on the response queue, and remains there.

I assume the reply handler is missing some transaction commit, causing some
automatic rollback, so the reply bounces back to the reply queue. Is that
correct?

How should/can I avoid this? I have read something about the
"transactedInOut" option, but it is currently deprecated, and setting it on
the request queue doesn't seem to help.

This is the proxy and surrounding request-reply route:

<bean id="testHelloProxy"
class="org.apache.camel.spring.remoting.CamelProxyFactoryBean">
   <property name="serviceUrl" value="direct:testHello"/>
   <property name="serviceInterface"
value="com.mazdaeur.mgws.service.TestService"/>
</bean>

<camel:route id="testHello" autoStartup="true">
   <from uri="direct:testHello" />
   <camel:inOut uri="{{jms.queue.test.request}}"/>
</camel:route>

And the dummy echo service on the other side:

<route id="testEcho" autoStartup="true">
   <from uri="{{jms.queue.test.request}}" />
   <camel:transacted />
   <transform>
       <simple>Hello ${body} (id ${id}) </simple>
   </transform>
   <setHeader headerName="JMSCorrelationID">
      <simple>${in.header.JMSMessageID}</simple>
   </setHeader>
   <to uri="{{jms.queue.test.reply}}" />
</route>

Last, the 2 external IBM MQ queues referred by JNDI, including some camel
options:

jms.queue.test.request=jms:queue:jms/queue.mud_rt_snd.01?replyTo=jms/queue.mud_rt_rec.01&useMessageIDAsCorrelationID=true&jmsMessageType=Text&messageConverter=#simpleBeanInvocationConverter&transactedInOut=true

jms.queue.test.reply=jms:queue:jms/queue.mud_rt_rec.01


Running on camel-2.6.0, inside IBM WebSphere 6.1 and IBM MQ, most resources
referred by JNDI.


Any help pointing me into the good direction is greatly appreciated!

Thanks,

Tung

Search Discussions

  • Mathieu Lalonde at Oct 24, 2011 at 11:25 pm
    Hi Tung,

    Try removing the <to uri="{{jms.queue.test.reply}}" /> from your route.
    Normally, for InOut, you should not send the response back explicitly.  Camel takes care of that for you. :)

    Good luck.

    Mathieu

    ----------------------------------------
    Date: Mon, 24 Oct 2011 18:21:02 +0200
    Subject: JMS request-reply and transactions
    From: wingtung.leung@gmail.com
    To: users@camel.apache.org

    Hello,

    I want to setup 2 separate routes in my camel context to create a
    synchronous spring bean method, which triggers a JMS based request-reply
    service.

    The front (synchronous) bean is invoked via a simple Spring web MVC
    controller, and dumps the response back to the browser. The second route, in
    a separate transaction, pulls the message from the request queue, performs a
    simple transformation and puts the response back into (shared) response
    queue (both queues from external IBM MQ server).

    At first, things were looking fine, because my browser page renders the
    response as expected. But in a second look, I discovered that the log still
    mentions a timeout (default 20 secs) waiting for the reply, although the
    reply has been received already! And secondly, after the timeout, the
    response message (re-) occurs on the response queue, and remains there.

    I assume the reply handler is missing some transaction commit, causing some
    automatic rollback, so the reply bounces back to the reply queue. Is that
    correct?

    How should/can I avoid this? I have read something about the
    "transactedInOut" option, but it is currently deprecated, and setting it on
    the request queue doesn't seem to help.

    This is the proxy and surrounding request-reply route:

    <bean id="testHelloProxy"
    class="org.apache.camel.spring.remoting.CamelProxyFactoryBean">
    <property name="serviceUrl" value="direct:testHello"/>
    <property name="serviceInterface"
    value="com.mazdaeur.mgws.service.TestService"/>
    </bean>

    <camel:route id="testHello" autoStartup="true">
    <from uri="direct:testHello" />
    <camel:inOut uri="{{jms.queue.test.request}}"/>
    </camel:route>

    And the dummy echo service on the other side:

    <route id="testEcho" autoStartup="true">
    <from uri="{{jms.queue.test.request}}" />
    <camel:transacted />
    <transform>
    <simple>Hello ${body} (id ${id}) </simple>
    </transform>
    <setHeader headerName="JMSCorrelationID">
    <simple>${in.header.JMSMessageID}</simple>
    </setHeader>
    <to uri="{{jms.queue.test.reply}}" />
    </route>

    Last, the 2 external IBM MQ queues referred by JNDI, including some camel
    options:

    jms.queue.test.request=jms:queue:jms/queue.mud_rt_snd.01?replyTo=jms/queue.mud_rt_rec.01&useMessageIDAsCorrelationID=true&jmsMessageType=Text&messageConverter=#simpleBeanInvocationConverter&transactedInOut=true

    jms.queue.test.reply=jms:queue:jms/queue.mud_rt_rec.01


    Running on camel-2.6.0, inside IBM WebSphere 6.1 and IBM MQ, most resources
    referred by JNDI.


    Any help pointing me into the good direction is greatly appreciated!

    Thanks,

    Tung
  • wing-tung Leung at Oct 25, 2011 at 8:49 am

    On Tue, Oct 25, 2011 at 1:24 AM, Mathieu Lalonde wrote:

    Try removing the <to uri="{{jms.queue.test.reply}}" /> from your route.
    Normally, for InOut, you should not send the response back explicitly.
    Camel takes care of that for you. :)
    This solved my problem, thanks Mathieu!

    I assume that the fixed echo route, detects the JMSReplyTo header in the
    message and automatically forwards the result of the route to that reply
    destination.

    This is some kind of test setup, the final echo implementation would not be
    using Camel, but written in some external mainframe application. I guess
    that program needs to behave accordingly and put the reply in the correct
    destination.

    But I don't understand what went wrong in the previous setup, where I send
    the reply explicitly the the reply destination. The initial request route
    sees an valid response, so I assume the echo route is finished and has
    committed the response.

    Why does the request route still logging some request timeout after a
    "successful" receive? And secondly, why do I find a reply message in queue
    after the timeout? Is it because the echo route posts TWO (!) messages?

    Anyway, my initial problem is solved, and having a better understanding of
    Camel JMS would only be a bonus .. :-)

    Thanks!

    Tung
  • Mathieu Lalonde at Oct 25, 2011 at 4:05 pm
    Tung,

    When using JMS with an InOut pattern, camel-jms will take care of the sending the reply using JMSReplyTo.
    If you send your response explicitly to a given queue at the end of your route, lets call it "queueXYZ", camel-jms will actually wait for a reply from queueXYZ so that it can send the final response to your reply queue!

    In your case, it never got a response back from jms.queue.test.reply so the timeout expired! ;)
    As for the 2nd message, I am not sure if it was an exception message or not.

    Cheers,
    Mathieu




    ----------------------------------------
    Date: Tue, 25 Oct 2011 10:48:02 +0200
    Subject: Re: JMS request-reply and transactions
    From: wingtung.leung@gmail.com
    To: users@camel.apache.org
    On Tue, Oct 25, 2011 at 1:24 AM, Mathieu Lalonde wrote:

    Try removing the <to uri="{{jms.queue.test.reply}}" /> from your route.
    Normally, for InOut, you should not send the response back explicitly.
    Camel takes care of that for you. :)
    This solved my problem, thanks Mathieu!

    I assume that the fixed echo route, detects the JMSReplyTo header in the
    message and automatically forwards the result of the route to that reply
    destination.

    This is some kind of test setup, the final echo implementation would not be
    using Camel, but written in some external mainframe application. I guess
    that program needs to behave accordingly and put the reply in the correct
    destination.

    But I don't understand what went wrong in the previous setup, where I send
    the reply explicitly the the reply destination. The initial request route
    sees an valid response, so I assume the echo route is finished and has
    committed the response.

    Why does the request route still logging some request timeout after a
    "successful" receive? And secondly, why do I find a reply message in queue
    after the timeout? Is it because the echo route posts TWO (!) messages?

    Anyway, my initial problem is solved, and having a better understanding of
    Camel JMS would only be a bonus .. :-)

    Thanks!

    Tung
  • Kannappan123 at Apr 24, 2013 at 7:16 am
    I have a similar problem. I have Request Reply queue.

    My (Component / ArtifactId / URI) is like this
    jms-mq:planRequestQueue?replyTo=planReplyQueue

    I have set ExchangePattern to InOut

    I can successfully drop a message on to planRequestQueue and receive the
    reply message on the planReplyQueue. However on the reply queue, the
    connection (open input count) is NOT closed.

    I have tried adding transactedInOut but that does not even connect to the
    reply queue
    jms-mq:planRequestQueue?replyTo=planReplyQueue&transactedInOut=true

    As suggested, I have removed the reply queue and just have
    jms-mq:planRequestQueue

    This only lets me drop the message on the requestQueue and does not even
    connect to the reply queue. The reply message is just lying there on the
    reply queue.



    --
    View this message in context: http://camel.465427.n5.nabble.com/JMS-request-reply-and-transactions-tp4933166p5731393.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Kannappan123 at May 13, 2013 at 5:29 am
    I have now fixed the leak, the by calling producerTemplate.stop();



    --
    View this message in context: http://camel.465427.n5.nabble.com/JMS-request-reply-and-transactions-tp4933166p5732383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedOct 24, '11 at 4:21p
activeMay 13, '13 at 5:29a
posts6
users3
websitecamel.apache.org

People

Translate

site design / logo © 2022 Grokbase