davsclaus commented on code in PR #27340:
URL: https://github.com/apache/camel/pull/27340#discussion_r4181087886
##########
core/camel-core-processor/src/main/java/org/apache/camel/processor/errorhandler/RedeliveryErrorHandler.java:
##########
@@ -1214,10 +1214,46 @@ private void runAsynchronousRedelivery() {
LOG.trace("Scheduling redelivery task to run in {} millis for
exchangeId: {}", redeliveryDelay,
exchange.getExchangeId());
}
- executorService.schedule(() ->
reactiveExecutor.schedule(this::redeliver), redeliveryDelay,
+ if (currentRedeliveryPolicy.isAllowRedeliveryWhileStopping()) {
+ executorService.schedule(() ->
reactiveExecutor.schedule(this::redeliver), redeliveryDelay,
+ TimeUnit.MILLISECONDS);
+ } else {
+ // the redelivery is not allowed while stopping, so wake up
every second to check whether we are
+ // preparing for shutdown, the same as the synchronous
redelivery does (see sleep())
+ scheduleAsynchronousRedelivery(new StopWatch());
+ }
+ }
+
+ private void scheduleAsynchronousRedelivery(StopWatch watch) {
+ long delay = Math.max(0, Math.min(1000, redeliveryDelay -
watch.taken()));
Review Comment:
Question (non-blocking): with `allowRedeliveryWhileStopping=false`, every
pending async redelivery now gets a scheduler task plus a reactive-executor hop
once a second for its whole delay (up to 60s by default, more if
`maximumRedeliveryDelay` is raised). With many exchanges waiting for
redelivery, that is N wake-ups per second on the error handler pool. Did you
consider tracking the pending scheduled futures and firing or cancelling them
from `prepareShutdown()` instead? If you keep polling for parity with
`sleep()`, that is fine; please just confirm the overhead is acceptable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
