Not sure if this belongs here, or in item, or even setup. Apologize if in wrong place.
Overview: Been running OH for about 2 years now, from 2.x and now to 3.x. I have a couple hundred “things” and about 2000 “items”. I only have a few rules, but am starting to add more and more complex scripts and rules. Long story short I ended up murdering my system with bad rules. I’m aware of this and am working on making those better. Alot of my behind the scene magic is done with cron jobs, and use of the API. The 3.x upgrade requiring auth is having me rethink these methods.
Right now I have some Exec scripts that run shell/python/etc scripts that populate items with various data sources. I found some of these scripts were poorly behaving, causing threads to hang on for long periods of time, eating up all various precious thread limits. This combined with my poor rules ate up even more. I’ve identified these scripts and rules by examining my blocked threads and java children. I also wrote some quick scripts to give me a count (via karaf console) and put # of children, waiting, blocked, rules, etc into items. This way I can record them over time in grafana, and maybe have a rule if they exceed a certain number.
Now for the question. Am I over complicating this? Did I write a script for something that already exists? Is/can the Openhab system be aware of it’s own state? Can it act on these without me jamming the data in externally? An internal item definition for karaf data?
Rule examples
if number of threads > 500 then update wall displays with message, or something similar.
if number of blocked threads > 10 then play screaming goat and update display, etc
Any suggestions? Is this overkill? Has/can this be solved in a better manner?
Maybe but not for the reasons you think. In OH 3 there is no more rules thread pool. Each rule gets its very own thread to use for as long or as little as it wants to. The only limitation is that only one copy of a given rule can run at a time so if the rule gets triggered while it’s still running from the last trigger, it will wait for the rule to finish before processing the second trigger.
So a lot of the problems with long running rules is simply gone in OH 3. The types of problems that can be caused by long running rules is now limited to a single rule. You can’t break all rules with long running rules any more.
As for the other questions, I don’t know if I can answer these or not without more explicit information and what specific problems you are having in OH 3 and whether the above actually solves your problems or if the problem is caused by something else.
hmmm well then I might have some digging to do. I still had some rule problems, and situations where I would flood my Zwave network in a Massive update storm. Despite all the warnings I was sleeping threads, shame on me. I’m working on those now tho. Guess I have new questions now tho.
I still see a threadpool config, (discovery, ruleEngine, safeCall, thingHandler) how do these play-out in OH3.
Does the same apply for all rules, of every type?
How does (if at all) does long running, or continued connections to API, and karaf have on performance, thread count. I tend to leave VS Code IDE open in background for days while playing, and/or a log tail in a terminal and forget about it.
I don’t know. But I do know that I was the one who fingers the issue that ultimately eliminated the thread pool for rules. Those may be left over settings.
Yes, I think so. But I don’t know for sure. Time based might come out of a thread pool. But I don’t think so.
