Closing the connection to mqtt broker for tcp://edge-message-bus:1883" file="mqtt/mqtt.go:165" #3330
Comments
|
Hi @gaurangomar, looks like you have issue an update command then the rule stops. Could you please check your rule payload, make sure triggerred=true is set. |
|
Thanks @ngjaying I am not able to find the documentation for |
|
It is not documented. It is just a property of the rule like this: { "id": "rule_scene", "triggered": true, "sql": "Select * FROM stream", "actions": [ { "nop": { "sendSingle": true } } ] } |
|
I am not passing this I believe setting property |
|
Do you use eKuiper manager to update the rule? Could you please find out how to reproduce the problem? Thanks. |
|
I am using the REST API, for creating and updating rules. curl --location 'http://kuiper-host:59720/rules' \
--header 'Content-Type: application/json' \
--data '{
"id": "RULE_CTR65AAA23ZG_7MX8KA5NKEE4",
"sql": "------SQL-----",
"actions": [
{
"mqtt": {
"server": "ttcp://edge-message-bus:1883",
"topic": "kuiper-sink",
"qos": 0,
"username": "user*****",
"password": "password******",
"retained": false
}
}
]
}'This issue is intermittent, i tried reproducing this on demand but not able to do it, I tried all my use cases. |
|
I don't think the info is enough to identify the problem. Form this little piece of log, it looks like someone has issued an update command and stop the rule intentionally or accidentally. If you have ever used eKuiper manager, the rule update may stop the rule if the triggered is not set to true by default. Could you find out why the rules are updated? Maybe a full log with description of the symtom (which rules stop unintentionally at what time etc.) is more helpful. |
|
Hi @ngjaying, Additionally I tried creating and updating rules manually but the rules are not getting stopped/closed they are working as expected. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
CPU family: 6
Model: 94
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NAME="Oracle Linux Server"
VERSION="9.0"
What happened and what you expected to happen:
We have multiple rules and we are experiencing an intermittent issue that rules are getting into stopped state.
We are using MQTT as a source and same MQTT broker as SINK.
Rules works fine but intermittently we see that some rules go into stopped state and stop processing data publishing to the source topic.
We are not able to see any error logs, below are the logs which we observed.
We are always sending structured data into the source topic, random/ raw entries will never exist in the source topic.
How to reproduce it (as minimally and precisely as possible):
We do not have any specific scenario to reproduce this issue, this is an intermittent issue.
We are using the
etc/mqtt_source.yamlfile for providing the source connection info, and for the SINK we use something like below.Anything else we need to know?:
Let me know in any other details are required.
The text was updated successfully, but these errors were encountered: