You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Mariusz Kosecki <ne...@gmail.com> on 2019/06/04 09:18:13 UTC
JMSReplyTo improperly utilised by camel to send an incomplete message
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.
Re: JMSReplyTo improperly utilised by camel to send an incomplete
message
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Since the route works as expected when you remove the split, I’d try moving all the split/aggregate logic into a direct route and call that from the main route and see if that works.
> On Jun 6, 2019, at 6:40 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> Mariusz I still have issues with the mailing list - he said:
>
> Hi,
>
> When I specify the consumer as "disableReplyTo=false" and remove the to("") at the end, then after replacing split() with process(mockSplitter) and aggregate() with process(mockAggregator), this works. The mocked message ends up on the receiver topic (as expected).
>
> For reference: mockSplitter is just a Processor that forwards the proper message type (its content is mocked up) and mockAggregator is a Processor that does the similar thing.
>
> So the question is: what is the problem with the split() in my route? Or is it something with unmarshal() or json() calls? Am I using those improperly?
>
> Also, to add some more insight: in my code (in the whole processing on the route), I'm only using exchage.in and I never touch exchange.out (so throughout the processing, each exchange.out appears as null, as it was never accessed). Does that matter?
>
> Thanks and regards!
>
>
>> On Jun 5, 2019, at 6:54 AM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> wrote:
>>
>> 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 <ma...@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 <ma...@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.
>>>
>>
>
Re: JMSReplyTo improperly utilised by camel to send an incomplete
message
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Mariusz I still have issues with the mailing list - he said:
Hi,
When I specify the consumer as "disableReplyTo=false" and remove the to("") at the end, then after replacing split() with process(mockSplitter) and aggregate() with process(mockAggregator), this works. The mocked message ends up on the receiver topic (as expected).
For reference: mockSplitter is just a Processor that forwards the proper message type (its content is mocked up) and mockAggregator is a Processor that does the similar thing.
So the question is: what is the problem with the split() in my route? Or is it something with unmarshal() or json() calls? Am I using those improperly?
Also, to add some more insight: in my code (in the whole processing on the route), I'm only using exchage.in and I never touch exchange.out (so throughout the processing, each exchange.out appears as null, as it was never accessed). Does that matter?
Thanks and regards!
> On Jun 5, 2019, at 6:54 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> 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 <ma...@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 <ma...@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.
>>
>
Re: JMSReplyTo improperly utilised by camel to send an incomplete
message
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <qu...@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 <ne...@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.
>
Re: JMSReplyTo improperly utilised by camel to send an incomplete
message
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <ne...@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.