MQTT 5 is an OASIS standard which debuted in March 2019. It boasts
numerous improvments over its predecessor (i.e. MQTT 3.1.1) which will
benefit users. These improvements are summarized in the specification
at:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901293
The specification describes all the behavior necessary for a client or
server to conform. The spec is highlighted with special "normative"
conformance statements which distill the descriptions into concise
terms. The specification provides a helpful summary of all these
statements. See:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901292
This commit implements all of the mandatory elements from the
specification and provides tests which are identified using the
corresponding normative conformance statement. All normative
conformance statements either have an explicit test or are noted in
comments with an explanation of why an explicit test doesn't exist. See
org.apache.activemq.artemis.tests.integration.mqtt5 for all those
details.
This commit also includes documentation about how to configure
everything related to the new MQTT 5 features.
- Avoid blowing up on string bodies of any size if the valueSizeLimit bits are configured to disable limit
- Dont NPE if amqp-value + binary body is sent without a content-type, as it always should be.
- Include expected prefix when adding delivery delay and ingress time annotations.
- Use the actual name for ingress time annotation, as with all other annotations.
- Use correct object type when testing equality with content-type value.
- Use consistent case for 'groupId' in different properties.
The test I wrote for ARTEMIS-3513 is throwing a few convert exceptions
because of SimpleString versus String conversion
This commit is addressing the issue,
The previous commit (the one addressing ARTEMIS-3513) should provide the test for this change.
While converting a core message to an OpenWire message there may be an
error processing a property value. Currently this results in an
exception and the message is not dispatched to the client. The broker
eventually attempts to redeliver this message resulting in the same
error. Instead of throwing an exception the broker should simply log a
WARN message and skip the property. This will allow clients to receive
the message without the problematic property and the broker will not
have to attempt to redeliver the message again.
Justin Bertram
AntonRoskvist
Robbie Gemmell
Domenico Francesco Bruscino
Erwin Dondorp
Clebert Suconic
gtully
franz1981
Asukwo-comfort
Emmanuel Hugonnet