Messages lost after unsubscribe before receipt with Auto ACK #135
Assignees
Labels
Comments
|
I like your idea regarding a message draining as callback. I'll try to add test cases first. |
|
Haken dran. |
jmglsn
added a commit
that referenced
this issue
Nov 30, 2019
When clients use `auto ack` and `unsubscribe` it's possible that messages are considered as processed, while they have never been forwarded by `read`. In order to avoid accidental message los a DrainingConsumer state was added, that comes together with the `DrainingMessageException`. Access to `Parser` internal buffer has been simplified, by adding `isBufferEmpty`. Same applies for `Client` here `isBufferEmpty` and `flushBufferedFrames` were added.
jmglsn
added a commit
that referenced
this issue
Nov 30, 2019
When clients use `auto ack` and `unsubscribe` it's possible that messages are considered as processed, while they have never been forwarded by `read`. In order to avoid accidental message los a DrainingConsumer state was added, that comes together with the `DrainingMessageException`. Access to `Parser` internal buffer has been simplified, by adding `isBufferEmpty`. Same applies for `Client` here `isBufferEmpty` and `flushBufferedFrames` were added.
jmglsn
added a commit
that referenced
this issue
Nov 30, 2019
When clients use `auto ack` and `unsubscribe` it's possible that messages are considered as processed, while they have never been forwarded by `read`. In order to avoid accidental message los a DrainingConsumer state was added, that comes together with the `DrainingMessageException`. Access to `Parser` internal buffer has been simplified, by adding `isBufferEmpty`. Same applies for `Client` here `isBufferEmpty` and `flushBufferedFrames` were added.
jmglsn
added a commit
that referenced
this issue
Jun 15, 2020
When clients use `auto ack` and `unsubscribe` it's possible that messages are considered as processed, while they have never been forwarded by `read`. In order to avoid accidental message los a DrainingConsumer state was added, that comes together with the `DrainingMessageException`. Access to `Parser` internal buffer has been simplified, by adding `isBufferEmpty`. Same applies for `Client` here `isBufferEmpty` and `flushBufferedFrames` were added.
jmglsn
added a commit
that referenced
this issue
Jun 15, 2020
When clients use `auto ack` and `unsubscribe` it's possible that messages are considered as processed, while they have never been forwarded by `read`. In order to avoid accidental message los a DrainingConsumer state was added, that comes together with the `DrainingMessageException`. Access to `Parser` internal buffer has been simplified, by adding `isBufferEmpty`. Same applies for `Client` here `isBufferEmpty` and `flushBufferedFrames` were added.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Calling
unsubscribe()on theConsumerStatesends an unsubscribe frame to sever and waits for the receipt. While the client waits for the receipt, it is receiving further frames and writes them into the unprocessedFrames. After the receipt was received, the unsubscribe method replaces the state with a ProducerState leaving the application incapable of receiving the intermediate frames (between unsubscribe and receipt). (As the read method on the ProducerState throws an InvalidState exception).Our solution was to read frames directly from the Client, but that's not really nice and took us a lot of debugging to find the issue for lost messages 😄
The text was updated successfully, but these errors were encountered: