OpenHAB Rule Threads

Hi all,

I was wondering if anyone had any information on how to track the current threads active of rules in my openHAB setup.

I was reading Why have my Rules stopped running? Why Thread::sleep is a bad idea in it rlkoshak shows how there are 5 threads available for rules to run in and gives a sample table of how each of these rules are queued and assigned a thread to operate on. How can I capture this information in real time on my openHAB setup?

Also if there are any helpful links about the threading system within openHAB please post them below in your answers, I am unsure where the 5 threads number came from in the linked question.

I am running openHAB 2.5.2 on the RaspberryPi 3.

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.

1 Like

Thanks for the reply :grinning:. No I’m not changing anything just wanted to learn more about how openHAB is handles executing multiple rules at the same time and what it’s limits are thats all.

Also, be aware that the sleep/thread limitations only apply to the old rule engine.

So using the sleep command does not block up the openHAB threads? Have you got any info on how the new rule engine handles this problem?

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.

As I said, there never was a problem. Nor is there one in the old rule engine, since this limitation is by design…

ok… I think a little more thorough explanation may be in order here Scott

So if I use the same design as used in Why have my Rules stopped running? Why Thread::sleep is a bad idea it doesn’t matter the rule engine the same design problem will occur?

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

1 Like

What more is there to explain?! The old rule engine used a thread pool… the new one does not.

1 Like

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.

ok… not exactly… thanks Scott for explaining

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

1 Like

Ok that was a good explanation, the burden is now put on the hardware instead of limiting the the number of threads within openHAB. I will look into the thread pool and do some research on it.

Just so I had somewhere to start researching further, if the old engine used a thread pool is there a name on the design that is used in the new rule engine that I should be looking into?

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.

I have no idea what you are asking here.

I don’t think I refered to it as such Scott

you did :rofl:

now that is interesting and exciting

Sure you did…

The DSL is not a rule engine.