Replies: 1 comment
-
|
Same thing folks, this is a large feature request and your company has still never reached out about any kind of engagement. This is way beyond the scope of what I can handle for community members and issues that seem to be special requirements on your part. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
Removal of processed messages is performed by DurabilityAgent - cyclical batch processing of database operations. In these batch there is
DeleteExpiredEnvelopesOperationandCheckRecoverableIncomingMessagesOperation. Options used to control it are:Scenario:
Handledkeep_untilfield <= utcNow (a few hours have passed since processing, so it will delete all of them at once)If we set the JobFirstExecution variable to 2 hours from the application start - this will also delay the call to the first
CheckRecoverableIncomingMessagesOperation- which means that the unprocessed messages in the inbox will be moved by at least 2 hours from the application start - we lose the processing order (strict order scenario).Still, if we control that the message can be deleted (KeepAfterMessageHandling) after 4 hours of processing, if the unavailability lasts longer, duplication is possible during rebalancing.
Maybe when deleting, instead of comparing the time from the
keep_untilfield to the current time, it should be compared to the time of publication to the transport layer or addition to the inbox for the last received message, and this could be configured using options in DurabilitySettings.To Reproduce
The problem is non-deterministic and occurs when the transport layer is Kafka. Scenario is described in section above.
Expected behavior
CheckRecoverableIncomingMessagesOperationandDeleteExpiredEnvelopesOperationcould be processed independently when we want to process in sequential order. If there are messages with the status 'handled' in the inbox, they should not be deleted immediately after the application is started (if it was unavailable for some time, for example) in order to wait some controllable period of time for rebalancing after reconnecting to the transport layerAdditional context
Problem was discovered in cooperation with @dominikjeske.
Wolverine version: 4.10.1
Beta Was this translation helpful? Give feedback.
All reactions