Hi all Thanks a lot for the interesting answers.
@Quinn: The AMQ scheduler delay is a great way to accomplish this since it makes even the waiting queue completely obsolete. And if one cannot change the configuration to activate the AMQ scheduler, the route stop via ControlBus is also a good alternative to make #3 (and also #6) work. @owain: Thanks for the hint. Especially with my 1-day-delay the whole processing chain would become quite tardy :-) @Brad: Yeah, the additional timestamp header is a way to prevent exceeding the maxRetry, but it does not prevent the spinning of messages (or I did not fully understand). When I start the wait-consumer-route by scheduler and it contains 10 messages they are processed. The ones who do not find their data, will come back very soon and are consumed again (and again and again...) as long as the route is running. The timestamp just prevents that the retries are taken into account. The core "problem" of my question is that messages in queues are consumed immediately but I want them to be delayed in special cases. To delay messages by a strict schedule, I can use #3, but then I have to stop the route by ControlBus (Quinns suggestion). Stopping the route by scheduler let it run either too long (spinning of messages) or too short (messages do not get processed and therefore the delay is multiplied for these messages). To delay messages individually (fixed delay applied per message) #2 works with the mentioned problems and Quinns AMQ scheduler suggestion is probably the best way to do it. Thanks a lot Stephan Brad Johnson <brad.john...@mediadriver.com> schrieb am Do., 3. Nov. 2016 um 19:47 Uhr: > Owain, > > That's why my preference would be to use the chron job he mentioned and > just check my own timestamp in millis in a header or even putting the items > in a map and putting that on the queue. The map would have number of > retries, timestamp, and the actual data model he's working with. That > would keep it relatively simple and performant if not the most elegant > solution on the planet. > > On Thu, Nov 3, 2016 at 1:37 PM, owain <owain@integration.technology> > wrote: > > > Just be careful of using the Active MQ delay since unless you clean this > > header up, it propagates to every subsequent queue. Quite difficult to > > debug! > > > > > > > > -- > > View this message in context: http://camel.465427.n5.nabble. > > com/Best-way-to-build-a-wait-retry-loop-with-Camel-tp5789712p5789722.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > >
