85089a3210
The previous commit uncovered another bug that was hidden by it: `maybe_flush_after_async_reply` was sending a message to the wrong PID. It was sending a message to `self()` meaning to target a buffer worker, but `self()` in that context is never the buffer worker, it's the connector's worker. This change also revealed a race condition where the buffer workers could stop flushing messages. So we piggy-backed on the atomic update of the table size count to check if the buffer worker should be poked to continue flushing. This allows us to get rid of `maybe_flush_after_async_reply` altogether. |
||
|---|---|---|
| .. | ||
| include | ||
| src | ||
| test | ||
| README.md | ||
| rebar.config | ||
emqx_resource
The emqx_resource is a behavior that manages configuration specs and runtime states
for resources like mysql or redis backends.
It is intended to be used by the emqx_bridges and all other resources that need CRUD operations to their configs, and need to initialize the states when creating.
There can be foreign references between resource instances via resource-id. So they may find each other via this Id.
The main idea of the emqx resource is to put all the general code in a common lib, including
the config operations (like config validation, config dump back to files), and the state management.
And we put all the specific codes to the callback modules.
See
test/emqx_connector_demo.erlfor a minimalemqx_resourceimplementation;test/emqx_resource_SUITE.erlfor examples ofemqx_resourceusage.