Thats because you only use completion timeout right? Because upon restarting the timeout map is not re-created.
It really doesn't know how long time elapsed since the server crashed.
We could possible add an improvement/fix for this so upon restart Camel detects this corner case (only complete by timeout). And then re-create the timeout map, meaning the timeout will start from 0 again. The tricky part is that the timeout value can only be re-created if the timeout value was a fixed value. And in your case thats a dynamic based on a header.
Alternative we can add an option which tells Camel to always publish all the exchanges from the repository upon startup. In your case that seems maybe okay as you only complete upon timeout.
Finally we could consider adding information in the repository about the completion conditions, so that completionTimeout(header(TIMEOUT_VALUE) would be evaluated and its value stored in the repository. So if the header was 30000, then that value is stored. Then we can re-create the timeout map based on that value. The problem is that this requires additional fields to be stored in the repository and we have other stores which are JDBC based and that would require to add more columns in the SQL schema.
You are correct that I am only using timeout. I was thinking it was my completion criteria.
What are my current options? Is there a way to "touch" the Exchange thus re-initializing the timeout map?
I'm going to think about my completion criteria to see if I can force a completion. My gotcha is that I don't know a quantity of messages that I will receive.
Thanks for the response,
I just grabbed the latest SNAPSHOT for 2.8, I'll do some testing and, provide feedback.
Thank You, kind sir!