Fixed qos2_publish_handled_ invalidly remains issue. #986
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.
qos2_publish_handled_ is used for avoid qos2 publish handling twice or more. On publish receive, if it doesn't contain the packet_id, then handle the publish message and add the packet_id to qos2_publish_handled_. On pubrel receive, erase the packet_id from qos2_publish_handled_ because the publish packet that has the packet_id is no logner resend. It is the basic logic.
However, when user sends pubrec with error reason_code, then the communication partner doesn't send back pubrel due to the error. In this case, there is no chance to erase qos2_publish_handled_ entry.
It should be erased when user sends pubrec with error reason_code. This fix adds it.
qos2_publish_handled_ used to access from only on strand. But this addition introduce out of strand access. It is user's timing. So I introduced mutex for qos2_publish_handled_.