pem is base64 encoded instead of binary crt
peer_cert_as_username=crt breaks exhook proto utf8 parsing of username
crt cannot be used in a topic name due to being invalid utf8
pem cannot be used in a topic name due to having slashes
peer_cert_as_clientid = md5 allows to e.g. subscribe to "t/%c" with ACL
existing peer_cert_as_username combinations are unaffected.
Listeners are internally identifiered by the listen-on tuple
which is not UI friendly when we have to find a listener by this
'signature'.
The listeners are actually named in configs, but the names are
discarded in the parsing functions.
This commit is to keep the name and provide an API to find
listener by name (identifier).
- Rename `mqtt_retain_available` to `retain_available`
- Rename `mqtt_wildcard_subscription` to `wildcard_subscription`
- Rename `mqtt_shared_subscription` to `shared_subscription`
- Add `emqx_zone:unset_env/2` API for unit test
The erlang:process_flag(max_heap_size, MaxHeapSize) can only set a MaxHeapSize of `small integer`, which is smaller than 2^59 on 64-bit systems, and 2^27 on 32-bit systems.
* Delete response_topic_prefix
The Response-Infomation in CONNACK was misinterpreated, it should
not be a broker's global config, instead, it should be per-client
or even per-session prefix/suffix mechanism
* Delete request-response code from emqx_client
* Add request-response test code
* meck as default dependency --- temp workaround for dep-vsn-check
Prior to this change, there are some config entry which is not parsed
correctly. So if user modify config such as reconnect_interval for
bridge, the new config can not be taken into effect.
bridge.$name.transport was added before we decided to derive
transport portocol based on the 'address' config.
i.e. when it's a remote erlang node, use gen_rpc
otherwise (must be IP or hostnmae), we should estabilish mqtt connection
The simple logger handler is not removed if we set the `log.to=file` in
emqx.conf.
This might be an issue of OTP logger:
https://bugs.erlang.org/browse/ERL-788
I set the error_logger to silent as a workaround.
* 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
Formatting variables and then passing them into the logger functions leads
to performance issues. i.e.
```erlang
logger:debug("RECV ~s", [emqx_packet:format(Packet)])
```
Above message will only be printed when the current log level set to
`debug`, but the function emqx_packet:format/1 will always be evaluated no
matter what the current log level is.
OTP 21 provides a special meta-data named `report_cb`, which can be used
for lazy evaluation. The fun is only evaluated if the primary/handler log level
check passes, and is therefore recommended if it is expensive to generate
the message.
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
Prior to this change, you can just use CN or EN field from the client
certificate as username.
This change add a new option to allow user to use Certificate directly as
username.
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
Zaiming Shi