[
https://issues.apache.org/jira/browse/APLO-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943323#comment-13943323
]
Tom Smith commented on APLO-353:
--------------------------------
There appear to be two issues here:
* Under {{apollo-broker}}: {{Delivery.set(other)}} does not copy the {{ack}}
field.
* Under {{apollo-mqtt}}: the QoS value of an incoming PUBLISH message is not
being saved. This info is needed as part of the determination of the QoS value
of outgoing PUBLISH messages. According to the MQTT spec, the QoS of the
outgoing message should be the minimum of that of the incoming PUBLISH and that
of the corresponding SUBSCRIBE. A possible solution is:
** create a subclass of {{RawMessage}} that can store the QoS value of the
incoming {{PUBLISH}} in {{MqttSession.sendViaRoute()}}.
** In {{MqttConsumer}}, retrieve the qos value of the incoming {{PUBLISH}} as
well as the qos value of the appropriate subscription. Calculate and set
appropriate QoS for outgoing PUBLISH.
> MQTT QoS always downgraded to 0
> -------------------------------
>
> Key: APLO-353
> URL: https://issues.apache.org/jira/browse/APLO-353
> Project: ActiveMQ Apollo
> Issue Type: Bug
> Components: apollo-mqtt
> Affects Versions: 1.6
> Environment: Mac OS X
> Reporter: Eric Cheung
> Labels: qos
> Attachments: apollo-mqtt-qos2.pcap, apollo-mqtt-qos2.txt
>
>
> When subscriber subscribes with qos=2, and publisher sends PUBLISH with
> qos=2, Apollo changes it to qos=0 when sends to subscriber.
> Publisher Apollo Subscriber
> <-- SUBSCRIBE with qos=2
> --> SUBACK
> PUBLISH qos=2 --> --> PUBLISH qos=0
> PUBREC <--
> PUBREL -->
> PUBCOMP <--
> This is observed in the MqttQosTest test case. The assertion:
> 38 should_receive("1", topic)
> does not actually test the qos level received. However, I looked at packet
> capture and confirmed that in the qos/EXACTLY_ONCE/EXACTLY_ONCE case, the
> PUBLISH was downgraded from qos=2 to qos=0 when it goes through Apollo.
> (previously reported on mailing list on Feb 5, 2014)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
