Before this change, when shared dispatch ack is enabled (in config)
in case all subscribers are offline (all sessions gave negative ack)
the message is simply discarded.
In this change, it is ensured to have one session picked according to
configured dispatch strategy when no subscriber is online.
The messages dispatched in such scenario are then queued in session state.
* Fix the Exit in testcases
* Fix Exit in emqx_mod_sup_SUITE
* Update testcases for log_tracer
* Fix Exit in emqx_protocol_SUITE
* Add will_acl_check
* Fix more Exits
* Fix failed test case
Prior to this change, terry-xiaoyu enhanced the cuttlefish to
support emqx enterprise edtion configuration entries. But it cause 6
test case failed.
* Fix dep-vsn-check
1. Add do_add_route/1 do_add_route/2, do_delete_route/1,
do_delete_route/2 APIs in emqx_router module
2. Improve the code of emqx_trie module
3. Update the emqx_broker module to call the new APIs of emqx_router
* Add acking mechamism for shared dispatch
For QoS0 messages, no acking
For QoS1/2 messages, 'ACK' at any of events below:
- ACK when QoS is downgraded to 0
- Message is sent to connection process
'NACK' at any of events below:
- Message queue is full and the receiving session starts to drop old messages
- The receiving session crash
Upon 'NACK', messages are dispatched to the 'next' subscriber in the group,
depending on the shared subscription dispatch strategy.
* Fix issue#1874
Prior to this change, if user use one client connect emqx with mqtt
v3.1.1, the client subscribe the topic and publish message to this
topic, it would receive this message itself published, this commit
provide a configure option to let user ignore the message itself published.
This change fix issue 1874.
* Small Fix
* Fix bug
* Better design
* Fix compile warning and improve coverage
* Better design to solve the performance issue
* Fix typo
* Fix typo
* Delete spaces in end of lines.
* Do not use anonymous function
* Better performance
Prior to this change, emqx_client:start_link does 2 works in one call:
- init an erlang process for emqx_client
- send MQTT CONNECT to remote broker
But this solution have some drawbacks:
- the return value of `start_link` compiles the return values of the 2
works: {ok, Pid, MqttResult}. It is inconsistent with the return value
of `gen_statem:start_link`, may causes confusions.
- the return mode of the 2 works are different:
`start_link` should always return {ok, Pid} or {error, Reason}, but
connecting to mqtt may throw out exceptions as it handles the
socket. But the caller couldn't have thought of the exception, he would
pattern match on the result of `emqx_client:start_link`, but it crashed!
- If the init work succeed but the connection failed, the caller couldn't
get a Pid from the return value, but indeed it was created inside the
emqx_client. This hides the fact that the Pid was created, and when the
Pid dies, the caller would receive an message from a Pid it doesn' know about.
This change divived these 2 work into 2 APIs:
- `start_link/1` is to build and verify the options, and returns {ok,Pid}
(on success) or {error, Reason} (on failure).
- `connect/1` is to send MQTT CONNECT, and returns {ok, MQTTResult::properties()} or
{error, MQTTReason}. MQTT reason codes will contains in the `MQTTReason`.
