camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: JMSReplyTo improperly utilised by camel to send an incomplete message
Date Wed, 05 Jun 2019 12:54:26 GMT
Mariusz sent the following to me directly (he’s having trouble with the mailing list).

Hi,

First of all, you seem to have mixed the terms up a bit. "true" and "false" work the other
way than you described, aren't they?

Also: did you mean setting those on the consumer ("from") or producer ("to") side?

And lastly: camel does not send the reply at the end of the route (hence my OP!), it sends
it in the middle.

Just to recap - as this might be important - my route works as follows:
1) it processes the requests as MyRequest object,
2) then splits them into smaller Messages,
3) sends them to a REST service,
4) unmarshalls as MyResponse objects,
5) aggregates into a bulk object,
6) then processes it and turns into a text message at the end of the route

Camel uses JMSReplyTo destination and send an object of type MyRequest (between steps 1 and
2), which is clearly not the end of my route.
What is wrong here?


My responses are:

I did switch the true and false settings for disableReplyTo - my bad.

I would assume you’re looking for the JMS request/response functionality from the consumer
(the from), and you’d like the “aggregated bulk object” from step 5 above sent as the
response to the JMSReplyTo queue.   If it was working the way I remembered, you wouldn’t
need the to(jms…) at the end at all.  I’m wondering if the sub-routes created but the
split are effecting the functionality?  Can you try a simple test with out the split and see
if it behaves as expected?



> On Jun 4, 2019, at 8:32 AM, Quinn Stevenson <quinn@pronoia-solutions.com> wrote:
> 
> It’s been a while since I’ve implemented a route that implements JMS request-response,
but if I remember correctly, you need to choose whether Camel/Spring will handle the reply
or you will.
> 
> If you set disableReplyTo=true, Camel/Spring will send the reply using whatever is in
the exchange at the end of the route (so you don’t need the “to” at the end of the route).
 If you set disableReplyTo=false, then you’re responsible for taking the appropriate action
with the message.
> 
> HTH
> 
> 
>> On Jun 4, 2019, at 3:18 AM, Mariusz Kosecki <newsletters.temp@gmail.com> wrote:
>> 
>> Hello,
>> My route is as follows:
>> 
>> from("jms:topic:T.INPUT?disableReplyTo=false")
>> .process(requestProcessor)
>> .unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
>> .split(messageSplitter)
>> .process(restProcessor)
>> .unmarshal().json(JsonLibrary.Jackson, MyResponse.class)
>> .aggregate(messagesAggregator)
>> .process(responseProcessor)
>> .to("jms:topic:recipientTopic");
>> 
>> If I set disableReplyTo=true and convert JMSReplyTo into
>> CamelJmsDestinationName, I get the expected result: process the request and
>> send the response to the output topic.
>> But I cannot comprehend why would I need to disable reply to, when in fact
>> I want to utilise it.
>> Currently, when disableReplyTo is set to false, I will end up a gibberish
>> message on the output topic, which cannot be parsed and throws an exception
>> "ClassNotFoundException: (package name).MyRequest" - it seems that camel
>> utilises JMSReplyTo between the first unmarshal() and split(), which is
>> unwanted as the message processing is incomplete. Is this a bug? Is this
>> explicitly documented somewhere? Am I doing something wrong? Are there too
>> many steps in the route? Can anyone explain?
>> 
>> Kind regards.
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message