Replies: 2 comments 2 replies
-
|
Hey @jgslima, thanks for bringing this up! Yup, that's not expected, but also not a big deal. This is a mismatch between the scheduled time and the due time resulting in it rescheduling execution a few times before the due time comes and it executes. So it's really not doing much between those invocations. If you look at this logic here: We have This should be Also, I don't think the There are also apparently some edge cases involving the All in all, I think these edge cases are worth cleaning up, adding more trace logs, and having more unit test coverage for this. Would you be wiling to give it a shot? |
Beta Was this translation helpful? Give feedback.
-
|
Hello
I'm sorry, I am afraid I will not be able at this point. I already had to dedicate some fair amount of time just to understand the main changes and to properly adapt some things here. I intend to suggest other changes for the framework, for those I may be able to help more. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your attention |
Beta Was this translation helpful? Give feedback.
-
|
I made a few changes and it improved, but I still get the log from time to time: private void pollAndExecuteScheduled() {
Instant startTime = Instant.now().plus(Duration.ofMillis(5));
Instant dueTime = this.context.lastAcknowledgement.plus(this.ackInterval);
boolean shouldExecute = !startTime.isBefore(dueTime);
if (shouldExecute) {
logger.trace("Executing scheduled acknowledgement");
List<CompletableFuture<Void>> executionFutures = this.context.executeAllAcks();
if (executionFutures.isEmpty()) {
Instant now = Instant.now();
this.context.lastAcknowledgement = now;
logger.trace("Updating lastAcknowledgement to {}", now.toEpochMilli());
}
}
else {
logger.trace("Not executing scheduled acknowledgement. Start time: {}, dueTime: {}, lastAcknowldgement: {}", startTime.toEpochMilli(), dueTime.toEpochMilli(), this.context.lastAcknowledgement.toEpochMilli());
}
} |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I do not know the inner workings of the
BatchingAcknowledgementProcessorclass.When I turn
TRACElog level for it, I can see what seems a lot of execution schedulings, for very short intervals (1ms or even 0ms):It seems that every 1 second, there are these sequences of executions scheduled one right after another.
SqsMessageListenerContainerFactorycreated with the default ack configurations.Are all these successive, immediate executions expected? If so, what is the logic behind it?
Thank you
Beta Was this translation helpful? Give feedback.
All reactions