If a client has unconfirmed messages, there are some conditions when it will not
correctly process a request to unsubscribe from the destination that the
messages were received from. For example: if a QOS1 subscriber with
autoConfirm=false attempts to unsubscribe within its onMessage method (without
first confirming delivery of the message) then the unsubscribe request will not
be forwarded to the server - and the operation will never complete.
This seems to have been introduced by commit
c57e4696653b363e296c3c7e30c605a48feab908 and further modified by
commit 973d1c50184b5403a9fc9c55fae1e7208e935c7d which appear to guard against
an exception being raised by the auto-confirm logic if someone unsubscribes
from a topic just at the point a message is being delivered and auto-confirmed.
This commit fixes the problem in a slightly different way: by adding checking
to the confirm message code path which tests the state of the related
subscription before passing the confirm request to the Engine component.
If a client has unconfirmed messages, there are some conditions when it will not correctly process a request to unsubscribe from the destination that the messages were received from. For example: if a QOS1 subscriber with
autoConfirm=falseattempts to unsubscribe within its onMessage method (without first confirming delivery of the message) then the unsubscribe request will not be forwarded to the server - and the operation will never complete.This seems to have been introduced by commit c57e4696653b363e296c3c7e30c605a48feab908 and further modified by commit 973d1c50184b5403a9fc9c55fae1e7208e935c7d which appear to guard against an exception being raised by the auto-confirm logic if someone unsubscribes from a topic just at the point a message is being delivered and auto-confirmed.
This commit fixes the problem in a slightly different way: by adding checking to the confirm message code path which tests the state of the related subscription before passing the confirm request to the Engine component.