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 <[email protected]> > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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. >>> >> >
