fd360ac6c0
This makes the buffer/resource workers always use `replayq` for queuing, along with collecting multiple requests in a single call. This is done to avoid long message queues for the buffer workers and rely on `replayq`'s capabilities of offloading to disk and detecting overflow. Also, this deprecates the `enable_batch` and `enable_queue` resource creation options, as: i) queuing is now always enables; ii) batch_size > 1 <=> batch_enabled. The corresponding metric `dropped.queue_not_enabled` is dropped, along with `batching`. The batching is too ephemeral, especially considering a default batch time of 20 ms, and is not shown in the dashboard, so it was removed. |
||
|---|---|---|
| .. | ||
| i18n | ||
| 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.