You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up during discussion between Wiebe and Matthijs as an improvement.
We noticed that when changing MQTT service enabled/disabled settings in gui-v2 wasm, the UI got half-stuck: browsing around it still worked ofcourse, but all MQTT comms was halted.
Until we refreshed the browser.
And the assumption is that this is caused by FlashMQ being restarted.
Wiebe will look into this further.
Wiebe has looked into it. We can get rid of the round-about way of how FlashMQ is started and restarted through wrapper scripts.
Plan:
Include hot-reloadable bridges in FlashMQ
The wrapper /usr/sbin/start-flashmq probably does not need to do the management of the /run/flashmq/vrm_bridge.conf symlink anymore. It can be done directly from Venus Platform.
Change Venus Platform to reload FlashMQ instead of restart.
Refactor /usr/sbin/mosquitto_bridge_registrator.py to not issue svc -t
The text was updated successfully, but these errors were encountered:
FlashMQ is restarted by Venus Platform on change of 'VRM settings -> two way communication'.
I have proof of concept code done for dynamically adding and removing bridges without the need for a restart. Changing the bridge config (usernames, password, host, etc) is a different story, but simply adding and removing should be possible soon.
That means venus-patform needs to be adjusted to not restart but reload FlashMQ when already running.
Also, I think /usr/sbin/mosquitto_bridge_registrator.py doesn't have to issue a FlashMQ restart anymore. There is some code to detect changes in /data/conf/flashmq.d/vrm_bridge.conf and then restart, but generation of that file should be idempotent and atomic nowadays: in otherwords: fully correct or empty. But, I would to discuss that with @jhofstee .
FlashMQ 1.12.0 with hot-reloadable bridges has been released.
Now Venus can be changed to not restart FlashMQ when 'two way communication' (or the yet-to-be-created 'VRM full access' setting). As far as I know, there currently is no support in Venus Platform to signal reload to running deamons based on config changes. So, some discussion may be required.
wiebeytec
changed the title
look into changing flashmq config without restarting it
Reload instead of restart FlashMQ on bridge config changes
May 3, 2024
This came up during discussion between Wiebe and Matthijs as an improvement.
We noticed that when changing MQTT service enabled/disabled settings in gui-v2 wasm, the UI got half-stuck: browsing around it still worked ofcourse, but all MQTT comms was halted.
Until we refreshed the browser.
And the assumption is that this is caused by FlashMQ being restarted.
Wiebe will look into this further.Wiebe has looked into it. We can get rid of the round-about way of how FlashMQ is started and restarted through wrapper scripts.
Plan:
/usr/sbin/start-flashmq
probably does not need to do the management of the/run/flashmq/vrm_bridge.conf
symlink anymore. It can be done directly from Venus Platform./usr/sbin/mosquitto_bridge_registrator.py
to not issuesvc -t
The text was updated successfully, but these errors were encountered: