Hi Claus & Mitko, Thanks for the replies. I actually went forward with the route activation/deactivation scheme and my solution looks like follows:
from(quartzScheduler) .to(beanWhichActivatesResendRoute).delay(5000L) .to(beanWhichDeactivatesResendRoute); from(...).routeId(RESEND) // route is initially not activated .to(...) Since the messages may fail again, I put any failed resends in a temporary dead letter queue. Then, when the resend route is deactivated, the bean also activates another route which pumps the failed resends from the temporary queue back into the resend queue. This is so there isn't a loop of furiously resending when resends fail. Here I decided that 5 seconds is enough :) The quartz scheduler will likely schedule every one hour or something like that in production. Do you see any problem with this approach? Thanks a ton for the answers, plus, Camel is awesome! Keep up the great work. BR, Lunchbox -- View this message in context: http://camel.465427.n5.nabble.com/Scheduled-Polling-Consumer-on-FTP-endpoint-tp472602p4578777.html Sent from the Camel - Users mailing list archive at Nabble.com.
