Prevent cursor from using more than 100% temp store#2165
Merged
Conversation
This fixes a bug in FilePendingMessageCursor that could cause the temporary store to exceed 100% usage. The cursor now properly checks the temporary usage limits when writing messages from memory to the temporary store. If the store is full, messages are now discarded and a discarded advisory will be fired (if enabled) and the messages will be DLQ'd if the processNonPersistent flag is true. This commit also fixes an issue with Topic subs possibly sending expired messages to the DLQ twice which was noticed while working on this fix.
mattrpav
requested changes
Jul 2, 2026
|
|
||
| private void discardMessage(MessageReference reference) { | ||
| try { | ||
| LOG.debug("Discarding message {}", reference); |
Contributor
There was a problem hiding this comment.
nit: I think the log should say why it is discarding in the message -- temp space full, temp space disabled, expired, etc
cshannon
added a commit
that referenced
this pull request
Jul 2, 2026
This fixes a bug in FilePendingMessageCursor that could cause the temporary store to exceed 100% usage. The cursor now properly checks the temporary usage limits when writing messages from memory to the temporary store. If the store is full, messages are now discarded and a discarded advisory will be fired (if enabled) and the messages will be DLQ'd if the processNonPersistent flag is true. This commit also fixes an issue with Topic subs possibly sending expired messages to the DLQ twice which was noticed while working on this fix. (cherry picked from commit 4c34a49)
cshannon
added a commit
that referenced
this pull request
Jul 2, 2026
This fixes a bug in FilePendingMessageCursor that could cause the temporary store to exceed 100% usage. The cursor now properly checks the temporary usage limits when writing messages from memory to the temporary store. If the store is full, messages are now discarded and a discarded advisory will be fired (if enabled) and the messages will be DLQ'd if the processNonPersistent flag is true. This commit also fixes an issue with Topic subs possibly sending expired messages to the DLQ twice which was noticed while working on this fix. (cherry picked from commit 4c34a49)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes a bug in
FilePendingMessageCursorthat could cause the temporary store to exceed 100% usage. The cursor now properly checks the temporary usage limits when writing messages from memory to the temporary store. If the store is full, messages are now discarded and a discarded advisory will be fired (if enabled) and the messages will be DLQ'd if theprocessNonPersistentflag is true. This commit also fixes an issue with Topic subs possibly sending expired messages to the DLQ twice which was noticed while working on this fix.While not a common scenario, previously it was possible to blow past the limits for the temporary store because FilePendingMessageCursor did not check if usage was 100%. This could happen if there was a small temporary store configured, or just simply a lot of destinations using temporary usage. In the worst case scenario this could mean filling up a partition and causing an IO exception and broker crash, best case it would still be bad because it uses up disk space meant for persistent messaging.