This commit upgrades the rulesql dependency to version 1.5 instead of
1.4. The difference between these two versions is that strings surrounded
by ' and " are supported in FROM clauses in version 1.5, but in version
1.4, only strings surrounded by " are supported.
Fixes:
https://emqx.atlassian.net/browse/EMQX-9243
Fixes https://emqx.atlassian.net/browse/EMQX-9130
Since buffer workers always support async calls ("outer calls"), we
should decouple those two call modes (inner and outer), and avoid
exposing the inner call configuration to user to avoid complexity.
For bridges that currently only allow sync query modes, we should
allow them to be configured with async. That means basically all
bridge types except Kafka Producer.
Fixes https://emqx.atlassian.net/browse/EMQX-9325
Currently, ingress bridges referenced in the `FROM` clause of rules
are not being accounted as dependencies.
When we try to delete an ingress bridge that's referenced in a rule
like `select * from "$bridges/mqtt:ingress"`, that bridge does not
trigger an UI warning about dependent actions.
This commit adds more content to the readme file of the `emqx_rule_engine`
app. The aim of the changes are to make it easier to understand what the
rule engine is and what it does.
Fixes:
https://emqx.atlassian.net/browse/EMQX-9229
A lot of the string value fields had default value defined in
schema as list-string rather than binary-string.
This caused the generated schema dump (in JSON format)
to have raw_default field as an integer array.
now a dot is allowed in front of a var (path)
e.g. ${.clientid} is equivalent to ${clientid}
${.} however, means everything.
the parsed var is interally represented as $_THIS_
to make it easier to read/search.
https://emqx.atlassian.net/browse/EMQX-8502
When a bridge is disabled, its metrics are reset. With this change,
we make rule actions behave like that: disabling a rule will reset its
metrics.
In the previous, when you query the tail pages, all the front of rows
will be queried out and formatted. It greatly hurts the speed of query.
Currently, we only format the final result rows. i.e, the query for the
last page of data will be 10x faster.
This commit adds a rule engine configuration option for changing the
implementation module used for the rule engine function jq. The two
options are `jq_port` (uses Erlang port programs to interact with jq)
and `jq_nif` (uses an Erlang NIF library to interact with jq).
Thanks to @terry-xiaoyu (Xinyu Liu <506895667@qq.com>) for Chinese
translations
Due to:
* Cluster RPC MFA is not idempotent!
* There is a lack of rollback for callback's side-effects
For instance, when two nodes try to add a cluster-singleton
concurrently, one of them will have to wait for the table lock
then try to catch-up, then try to apply MFA.
The catch-up will have the singleton created, but the initiated
initiated multicall apply will fail causing the commit to rollback,
but not to 'undo' the singleton creation.
Later, the retries will fail indefinitely.
Prior to EMQX 5.0, the edge edition's main difference comaring
to standard edition are:
* Less number of plugins in the release (smaller package size)
* Smaller number is vm.args (for lower memory usage)
Starting from 5.0 most of the plugins are included as features,
the tuned vm.args arguments does not justify a special release edition.
Also as nanomq is getting mature,
EMQ's recommendtation for MQTT broker in edge is https://nanomq.io/
This commit adds a default timeout of 10 seconds to the rule engine's
`jq/2` function, and adds a new function `jq/3` (where the last parameter is
a timeout value). The default timeout can be configured with the setting
"rule_engine.jq_function_default_timeout".
Having a timeout when executing jq code in the rule engine is important
as jq code can potentially run forever. Also, the Erlang jq library
limits the number of jq programs that can execute concurrently so a jq
program that loops forever could potentially also prevent a "non-buggy"
jq program from ever starting.
Zaiming (Stone) Shi