* 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`.
Fixed bugs:
- Priority queue lack of a `len + 1` logic in `in/2`
Changed behaviors:
- Topics not found in priority table (from config) will be treated with default priority,
instead of hasing topic name to a priority number.
- Default priority is now configurable (it was always lower than all configured priorities)
- The dropped message due to reaching `max_len` is now returned from `in/2`,
so the queue owner (`in/2` caller) can perform autopsy on it
Add request & response support for CONNECT & CONNACK
Prior to this change, there is no validate and specified process for
Request-Response-Information and Response-Information
Also added basic Request/Response functionality to emqx_client implementation
Before this change, the stats callback provided by emqx_broker_helper
was an anonymous function with module local context.
This commit changes it to a full fun M:F/A style callback for:
1. More robust to hot beam reload
2. Faster/smaller variable to construct
3. Easier test
Before this change, eqmx_mock_client uses a shared ets table
to store last received message, this causes troulbe when we
want to start / stop two or more clients in one test case
the ets table gets owned by the first spanwed client and
gets closed when the owner client dies.
Now it keeps the last received message in process state
and a gen_server call is added to retrieve it for verification
Along with this change in emqx_mock_client, it made possible
to write test case to verify the actual subscriber pid
used in shared subscription strategy, so test cases were
added (and modified) to verify different strategies
The hibernation behaviour is also changed (implicitly) in this commit:
Prior to this change, connection/session always hibernates after
the stats timer expires regardless of messages in mailbox.
After this commit, connection/session process only goes to hibernate
when the timer expires AND there is nothing left in the mailbox to
process
The implementation prior to this commit supports
only one gc enforcement policy which is message count threshold.
The new implementation introduces 1 more: volume threshold based
Prior to this change, listeners test suites did not start cowboy which
is responsible for websocket connections. and access suites start
duplicated processes and these actions are wrong
This change fix the problem states above.
tigercl