[mapdb] Persistence service blocks item notifications

[J-N-K]

MapDB block item thread pool when a lot of states are stored.

Discovered in openhab/openhab-core#3578

[J-N-K]

@openhab/add-ons-maintainers It could be that this also affects other persistence add-ons. Someone might want to check that.

[jlaur]

@J-N-K - thanks for sharing, I have checked jdbc, and it also suffers from this problem. It even makes synchronous network calls during store.

[J-N-K]

That's similar to what influxdb does.

[lolodomo]

I just have a quick look to rrd4j persistence service and the store of data is synchronous too. So I guess it should be also fixed.

PS: you made an incredible discovery @J-N-K , strange that it was not detected before.

[florian-h05]

PS: you made an incredible discovery @J-N-K , strange that it was not detected before.

I had serious performance issues where groups nearly completely missed state updates from their members, so thanks again for finding the root cause @J-N-K!

[J-N-K]

Similar issues were already reported earlier, but the reports did not contain enough information to find it. I believe that at least some of the issues like openhab/openhab-core#3531 have similar reasons.

[lolodomo]

I had serious performance issues where groups nearly completely missed state updates from their members

It happened when you had a massive number of state updates, is that correct ?

The problem is that all persistence services have probably to be updated. Priority should be RRD4J which is the default persistence service and so probably used by most users, and the most used persistence services (JDBC is probably one of them).

[florian-h05]

Similar issues were already reported earlier, but the reports did not contain enough information to find it.

Then I'm glad I was able to provide enough information!

It happened when you had a massive number of state updates, is that correct ?

Correct. e.g when I turned my light Florian_Licht on/off, the F2_Florian_Licht, F2_Florian, gLicht groups were informed, which are nested in other groups, and for each Item the PersistenceManager as well. This lead to peaks of over 30 listeners to get informed in one second, which were scheduled but never executed because the thread was too busy with persistence. Seehttps://github.com/openhab/openhab-core/issues/3578 for more information.

The problem is that all persistence services have probably to be updated. Priority should be RRD4J which is the default persistence service

As Jan said in the core issue, the problem is that the persistence services did not implement PersistenceService.store well, see openhab/openhab-core#3578 (comment).

And I agree that RRD4J should be the top priority.