When big messages are produced if a consumer receives an expired message, the credits are not updated, so if the consumer is too slow and an expiry delay has been set, we can end up with a situation where there are no more credits which prevents the consumer from receiving any more messages.
In case the bindings "news.#" and "news.europe.#" are registered, only the first one matches with the address "news.europe" while both are supposed to match. Those changes are meant to get rid of this limitation.
Durable subscrption state is part of the MQTT specification which has
not been supported until now. This functionality is implemented via an
internal last-value queue. When an MQTT client creates, updates, or
adds a subscription a message using the client-ID as the last-value is
sent to the internal queue. When the broker restarts this data is read
from the queue and populates the in-memory MQTT data-structures.
Therefore subscribers can reconnect and resume their session's
subscriptions without have to manually resubscribe.
MQTT state is now managed centrally per-broker rather than in the
MQTTProtocolManager since there is one instance of MQTTProtocolManager
for each acceptor allowing MQTT connections. Managing state per acceptor
would allow odd behavior with clients connecting to different acceptors
with the same client ID.
The subscriptions are serialized as raw bytes with a "version" byte for
potential future use, but I intentionally avoided adding complex
scaffolding to support multiple versions. We can add that complexity
later if necessary.
Some tests needed to be changed since instantiating an MQTT protocol
manager now creates an internal queue. A handful of tests assume that no
queues will exist other than the ones they create themselves. I updated
the main test super-class so that an MQTT protocol manager is not
automatically instantiated when configuring a broker for in-vm support.
* Unsetting the transation timeout on the TransactionManager after the
onMessage has been called
Issue: https://issues.apache.org/jira/browse/ARTEMIS-4427
Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>
The exception thrown by serverLocator.connect() should be all you need on such case
and the caller should then be responsible for taking appropriate action.
ARTEMIS-4408 Update docker-run.sh for etc override
After creating the artemis docker image using the docker-run.sh script,
it is not possible to map a user supplied broker.xml using a volume
mapping. The broker.xml file is not there before instance creation,
so we cannot a static file mapping.
This change introduces an etc-override folder to write over the etc
folder contents. If a folder named etc-override exists inside the
instance folder, its contents will be copied over to etc folder after
instance creation. In order to use custom files that reside in etc,
eg. broker.xml or artemis.profile; it is sufficient to place these
files to a folder and map it to /var/lib/artemis-instance/etc-override
folder of the image.
The usage is also documented in readme.md file under the docker folder.
