Add acking mechamism for shared dispatch #1872
Merged
Conversation
This file contains 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
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
from
0047c28
to
be02999
Compare
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
from
be02999
to
d93d875
Compare
spring2maz
changed the base branch from
shared-subscriber-should-key-by-group-id
to
emqx30
Pull Request Test Coverage Report for Build 3832
💛 - Coveralls |
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
2 times, most recently
from
02d9651
to
2de01a2
Compare
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
from
c6010a7
to
5f1b2d8
Compare
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
from
10101e5
to
58d69d5
Compare
For QoS0 messages, no acking For QoS1/2 messages, 'ACK' at any of events below: - ACK when QoS is downgraded to 0 - Message is sent to connection process 'NACK' at any of events below: - Message queue is full and the receiving session starts to drop old messages - The receiving session crash Upon 'NACK', messages are dispatched to the 'next' subscriber in the group, depending on the shared subscription dispatch strategy.
Prior to this commit, QoS-2 messages a published through the session process which can at the same time being a receiving process for messages published by other sessions. This works fine until we introduce synced-dispatch for shared subscription, because then there is a risk of deadlock of two (or more) processes sending to messages and waiting for acknowledges around the same moment. In this commit, the 'publish' call for QoS-2 messages have been replaced with 'register_publish_packet_id' and return immediately after the packet ID (and timestamp) is registered in the session process, the the publish work is done by caller (connection) process like the way QoS-0/1 messages are handled
Also nack if a message is dropped due to message queue being full
spring2maz
force-pushed
the
reliable-delivery-of-qos1-2-in-shared-sub
branch
from
58d69d5
to
af9dc10
Compare
gilbertwong96
approved these changes
Nov 21, 2018
tigercl
pushed a commit
that referenced
this pull request
Nov 24, 2018
* Add acking mechamism for shared dispatch For QoS0 messages, no acking For QoS1/2 messages, 'ACK' at any of events below: - ACK when QoS is downgraded to 0 - Message is sent to connection process 'NACK' at any of events below: - Message queue is full and the receiving session starts to drop old messages - The receiving session crash Upon 'NACK', messages are dispatched to the 'next' subscriber in the group, depending on the shared subscription dispatch strategy.
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.
For QoS0 messages, no acking
For QoS1/2 messages, 'ACK' if any:
'NACK' if any:
Upon 'NACK', messages are dispatched to the 'next' subscriber in the group,
depending on the shared subscription dispatch strategy.