You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Dejan Bosanac (JIRA)" <ji...@apache.org> on 2014/10/17 14:41:34 UTC

[jira] [Resolved] (AMQ-5399) MQTT - out of order acks

     [ https://issues.apache.org/jira/browse/AMQ-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dejan Bosanac resolved AMQ-5399.
--------------------------------
    Resolution: Fixed

Fixed with http://git-wip-us.apache.org/repos/asf/activemq/commit/28b45341

> MQTT - out of order acks
> ------------------------
>
>                 Key: AMQ-5399
>                 URL: https://issues.apache.org/jira/browse/AMQ-5399
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: MQTT
>    Affects Versions: 5.10.0
>            Reporter: Dejan Bosanac
>            Assignee: Dejan Bosanac
>             Fix For: 5.11.0
>
>
> As different QoS messages are acked at different points, we can get in the situation where broker gets message acks out of order, leading to exceptions like
> {code}javax.jms.JMSException: Unmatched acknowledge: MessageAck {commandId = 0, responseRequired = false, ackType = 2, consumerId = ID:mac.fritz.box-62188-1412945008667-1:3:-1:1, firstMessageId = null, lastMessageId = ID:mac.fritz.box-62188-1412945008667-1:2:-1:1:2, destination = topic://xxx, transactionId = null, messageCount = 1, poisonCause = null}; Expected message count (1) differs from count in dispatched-list (2){code}
> The same situation can occur in heavy load environments. The root of the problem is that we send back standard acks which should be in order. As we really ack message by message we should be using individual acks in mqtt filter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)