I recently upgraded some instances to 8.1.20 (in a portainer environment, in various VM and on a bare metal host) and I found a common behaviour.
After the upgrade, the gateway starts correctly and everything “seems” to be working, except the tags do not provide reliable information. Some are slower than the class assigned, some keep the last value read and never change, some are just blank.
After a restart of the tag provider (Configure->Realtime Provider->Open Provider->Save without any changes) or a restart of the gateway, everything goes back to normal.
8.1.20 installer is the only one that shows this behaviour. Would be nice to know if I am alone facing this issue or if it is widespread.
Hello, sorry with the delay, we had another planned upgrade and I wanted to collect some data.
It seems to happen especially to query tags. The provider we look at is remote, but the tags definitely don’t behave well on the source gateway. The query running on the tags doesn’t produce results almost like it’s not fired/not running in its scan class, even if we change the scan class. The same query run in the DB console works fine.
After a restart of the remote tag provider, query tags start updating again.
Your last assumption is correct, after the upgrade and first start, query tag seem to be misbehaving. After another restart, everything work properly.
Today I tried to restart just the tag providers (open → save) and it didn’t work, so I had to restart the whole gateway and things started to work again. I have a thread dump/logs if needed.
Unfortunately there was a regression introduced in 8.1.20 that can affect query tags that target the same database connection across different tag providers. There is a fix coming soon in 8.1.21 to mitigate this (it is not in the current RC, though). At the moment, a workaround is to define a duplicate database connection (with a different name) and use that to keep query tags on a given provider targeting their own database connection.