shell:threads in Karaf console.
But search the forum before posting, please. And mind you there is usually no need to mess with the default setting … you only need to take @rlkoshak’s advice NOT to use sleep for serious.
Some programmers seem to feel offended by that, but it’s really the best strategy here.
There’s no problem to handle, since no problem exists. Think of scripted automation as an addon. The only things limiting the number of threads an addon can spin up are available memory and the maintainers.
Sorry I guess what I was trying to ask was what was the solution that solved the problem and got rid of it in the new rule engine?
If the hardware and memory is still the same what has changed in the way openHAB handles threads in the new rule engine that the problem no longer exists? Sorry if I am asking too much just trying to understand how openHAB operates.
I just took from this reply that using the above design in the old rule engine causes a problem but using the same design in the new rule engine will not cause a problem as there has been a fix. I am just a bit confused now to be honest by what you meant by this. Has something actually changed or can this problem still occur by design?
Right, sorry Warren
the way the DSL rules engine works, thread sleep over 200 ms or so is dangerous. The way the new rules engine works. sleeping a thread is no big deal
I’m hoping someone who understands better will explain
Thanks Andrew for the reply. No worries any reply’s are helpful, so just to be clear from what you understand it is no longer a “design” problem as there has actually been a fix for this problem in the updated rule engine.
If someone was to use the same design with multiple sleeps in both the new and old rule engine, the impact of this problem would be reduced in the new rule engine due to this fix.
To explain from a new user’s point of view, the DSL rules engine has a thread pool which by default was 5 threads. It could be changed (increased) but ultimately the limitations of the hardware would prevail. Point is, using thread sleep with the default thread pool of 5 was considered a really bad idea if you had a bunch of rules running all the time.
The new generation rules engine does not have any such limitations on how many threads it can consume. but if you write equally terrible code you will still eventually bump up against the limits of the hardware platform, especially on something like a Pi
ok and edit to add… the new rules engine seems to run a lot more efficiently from all early reports
For clarification though… the rules DSL is not the old rule engine. The two are understandably confused, but they are completely different things. Depending on how things pan out for automation in OH 3.0, it is possible that the rules DSL may be setup to utilize the new rule engine in some capacity.
The new rule engine does not use a thread pool, but there are some things built into it that will help to prevent most users from messing things up too much. For example, only one instance of a rule’s action will be executed at a time, where the old rule engine could have multiple and eat of the thread pool.