When multiple clients try to connect concurrently using the same
client ID, they all call `emqx_channel:ensure_connected`, increasing
the live connection count, but only one will successfully acquire the
lock for that client ID. This means that all other clients that
increased the live connection count will not get to call neither
`emqx_channel:ensure_disconnected` nor be monitored for `DOWN`
messages, effectively causing a count leak.
By moving the increment to `emqx_cm:register_channel`, which is only
called inside the lock, we can remove this leakage.
Also, during the handling of `DOWN` messages, we now iterate over all
channel PIDs returned by `eqmx_misc:drain_down`, since it could be
that one or more PIDs are not contained in the `pmon` state.
* refactor(emqx_slow_subs): refactor use moving average
* fix(emqx_slow_subs): change elapsed to latency, and fix some error
* fix(emqx_slow_subs): fix emqx_mgmt_api.erl indent
* fix(emqx_slow_subs): change api name
* fix(emqx_slow_subs): fix and improve some code
* fix(emqx_slow_subs): move clienid filed from latency_stats to session
(Same as #6289 )
This adds the information from `proc_lib:initial_call/1` and the
current stacktrace from the process info to `emqx_sys_mon:procinfo/1`
to aid in debugging some warnings with no context such as the
following:
```
2021-11-23T12:33:59.387818+00:00 [warning] info: [{old_heap_block_size,45988046},{heap_block_size,22177879},{mbuf_size,0},{stack_size,40},{old_heap_size,22354134},{heap_size,7106339}], line: 130, mfa: emqx_sys_mon:handle_info/2, msg: large_heap, procinfo: [{pid,<0.2667.0>},{memory,579763664},{total_heap_size,68510672},{heap_size,22177879},{stack_size,40},{min_heap_size,233},{initial_call,{proc_lib,init_p,5}},{current_function,{gen,do_call,4}},{registered_name,[]},{status,running},{message_queue_len,360945},{group_leader,<0.1660.0>},{priority,normal},{trap_exit,false},{reductions,16493271},{last_calls,false},{catchlevel,4},{trace,0},{suspending,[]},{sequential_trace_token,[]},{error_handler,error_handler}]
```
* feat(trace): add http trace API
* feat: sub/unsub trace topic
* chore(trace): stream log use _page and _limit
* fix: elvis warning
* fix: mod_trace test failed
* fix: http api meta rename _page/_limit to _page/_limit
* fix: clientid string not working
* fix: add emqx_mod_trace to module
* fix(trace): fixed by review suggestions
In order to correctly display the number of connected clients in our
monitor dashboard, we need to track those connections that are
actually connected to clients, not considering connections from
persistent sessions that are disconnected. Today, the
`connections.count` that is displayed in the dashboards considers
those disconnected persistent sessions as well.
Prior to this fix, 'kick' and 'discard' calls may timeout (or
fail for other reason), failures lead to only a log, then
continue to allow the new session to get registered.
As a result, in case a client is stuck, there is no way to
force it to step down, end up with multiple connections (sessions)
for the client ID in dashboard.
After this fix, the stale pids are notified to shutdown
via a gen_server:call, and forced with a exit(Pid, kill) for any
exception happend to the gen_server:call
Prior to this commit, there was a bug in emqx_frame:split/2
the tail number of bytes was used for header number of bytes
whens split. As a result, if the tail happens to be longer
then haeder, the parsing state becomes invalid and it crashes
when the next packet arrives
The split was a over-engineered micro-optimization, so it
has been deleted instead of fixed
Prior to this change, plugin config files are only allowed
to be placed in the collective config dir etc/plugins.
In order to support external plugin's drop-in deployment,
this commit made emqx_plugins module to read conf file
in application's etc dir
zhongwencool