feat(mqtt-bridge): avoid middleman process #9870
Conversation
So that buffer worker would notice a connection loss in time, and recycle inflight messages subsequently.
keynslug
force-pushed
the
fix/mqtt-connection-loss-feedback
branch
2 times, most recently
from
8e4a13d
to
1bb0945
Compare
Instead, supervise `emqtt` client process directly.
keynslug
force-pushed
the
fix/mqtt-connection-loss-feedback
branch
from
1bb0945
to
30cb2f2
Compare
keynslug
force-pushed
the
fix/mqtt-connection-loss-feedback
branch
from
30cb2f2
to
c5a7cd5
Compare
| {ok, WorkerPid}. | ||
| case emqx_connector_mqtt_worker:send_to_remote_async(InstanceId, Msg, Callback) of | ||
| ok -> | ||
| % TODO this is racy |
There was a problem hiding this comment.
emqx_connector_mqtt_worker:send_to_remote_async/3 can return {ok, Pid} ?
| Fun() | ||
| catch | ||
| error:badarg -> | ||
| maps:get(badarg, Else); |
There was a problem hiding this comment.
it seems all badargs are mapped to disconnected, maybe simply return disconnected when badarg happens.
| catch | ||
| error:badarg -> | ||
| maps:get(badarg, Else); | ||
| exit:{noproc, _} -> |
There was a problem hiding this comment.
is noproc just a race condition of badarg ?
There was a problem hiding this comment.
if yes, it should return disconnected too ?
There was a problem hiding this comment.
Not exactly, AFAICS. This is what gen:call will throw when there's no pid behind a name, even when the gproc act as a registry.
if yes, it should return
disconnectedtoo ?
On a second glance the code seems a bit too complicated, so probably yes. I'll open a followup PR.
|
minor comment fix can be fixed in follow-up PRs. |
Instead, supervise
emqttclient process directly. New scheme should be much simpler than before.This currently has some minor drawbacks.
EMQX-8798