@Stephan,
The timestamp could prevent you from ever getting to the processing. Since
I don't actually have your code I can't tell for sure. Imagine consuming a
message from the queue and the very first thing you do is check the
timestamp. You haven't even tried to process it yet. If the timestamp
doesn't indicate the passage of a day, you put it back on the queue. The
worst case here is that it would pull the message off the queue multiple
times with multiple checks of the timestamp. But it wouldn't reprocess it
in any way.
If you wanted you could put a pause on the message before putting it back
on your queue if you're worried about checking the timestamp too often. So
something like:
1. Dequeue the message.
2. Check the timestamp before doing anything else. (This assumes mutliple
threads processing so pause wouldn't bog everything down)
<from uri="seda:input.queue?concurrentConsumers=10"/> <!-- Make the number
of concurrent as many or as few as you want. Could be settable via config
file. Check syntax as this is from memory-->
<choice>
<when>
<simple>check timestamp</simple>
<to uri="direct:ok.to.process.due.to.timestamp"/>
</when>
<otherwise>
<!--timestamp didn't show it to be ready to be processed again so let's
just sit here for a bit. You could make this a settable variable e.g.
"{{reprocess.delay}}" for the delay constant. .
<delay>
<constant>60000</constant> <!-- wait for 60 seconds
before dumping the message back on the end of the input queue. Or set to
whatever time you want.-->
</delay>
<to uri="input.queue"/>
</otherwise>
</choice>
On your ok.to.process call you'd do your max retry logic and process the
value. If reprocess fails, change the timestamp and put it back on the
input queue.
On Fri, Nov 4, 2016 at 4:42 AM, Stephan Burkard <sburk...@gmail.com> wrote:
> 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.
> > >
> >
>
