Apache Camel: Asynchronous delaying with Delayer not functioning properly - activemq

Question

I'm currently writing a Dead Letter queue to handle exceptions occurring within a route. In the dead letter queue I plan for each message to be delayed by 1 day (or any other long time). The code I have written currently delays the message properly except doesn't delay asynchronously and messages end up getting backed up while waiting for the previously delayed messaged to wait out their delay period.
<route>
<from uri="activemq:queue:foo"/>
<delay asyncDelayed="true">
<constant> 60000 </constant>
</delay>
<to uri="activemq:aDelayedQueue"/>
</route>
I read that asyncDelayed="true" should schedule a task to be executed in the future to process the latter part of the route except when I try to run the above code the messages end up backed up in the foo queue while trickling in 1 at a time for the aDelayedQueue.
Why would it do this and is there something that could fix this issue?
Thanks!
EDIT, I found a workaround but I'm curious to see what went wrong originally.
Rewording the question again. Here's what my queue pipeline looks like:
QueueA -> QueueB -> QueueC
QueueB pulls the messages that are in QueueA. The goal is for each message to sit in QueueB for X amount of time before being sent to QueueC. The above code snippet was placed in QueueB. The issue I was facing was that if 5 messages arrived simultaneously in QueueA, QueueB would only pull one of those messages in, wait the 60 seconds, then send that message off to QueueC. My intended functionality was for all 5 messages to get placed onto QueueB where they would sit for 60 seconds before being placed onto QueueC all at once. The original issue was that messages started to stack up in QueueA because QueueB was waiting on the delay.

Answer 1

The JMS client route handles messages one by one and not in parallel. Only, when one message leaves the queue, the next queue can enter the route. Therefore, if one message is delayed, no other message is read from the JMS queue.
Beside your workaround, you could have parallelized your route:
<route>
<from uri="activemq:queue:foo"/>
<to uri="seda:delayer"/>
</route>
<route>
<from uri="seda:delayer?concurrentConsumers=1000"/>
<delay asyncDelayed="true">
<constant> 60000 </constant>
</delay>
<to uri="activemq:aDelayedQueue"/>
</route>
However, your workaround AMQ_SCHEDULED_DELAYis more robust even if your client route shuts down, see Persisting failed messages in Camel's SEDA queue.

Answer 2

I had the exact same problem, except that the routes were vm routes as opposed to activemq. So, the following route definition would block synchronously:
from("vm:a").
throttle(1).asyncDelayed().
to("vm:b");
However, when I added the maximumRequestsPerPeriod value, it worked as expected:
from("vm:a").
throttle(1).asyncDelayed().maximumRequestsPerPeriod(100L).
to("vm:b");
If you don't provide a maximumRequestsPerPeriod value, it seems to not queue requests and thus blocks the caller.