Issue of the topic: Random delays
I’ve got a very large OH setup which I’ve recently migrated to V2.5.0 and MQTT2. Now the migration is complete I’ve noticed odd delays creeping in, possibly when there are many timers running.
Is there a limit to how many timers can run concurrently?
Do I need to increase something now I’ve moved from MQTT1 Item based configuration to MQTT2 thing based configuration?
I’ve already increased my rule execution threads so its unlikely to be that.
Define “timer”? The use of createTimer() in DSL rules?
Define “running”? Timers awaiting their appointed time effectively consume no resource.
Timer blocks actually executing share a small pool of threads. That was some small number up to OH 2.4, has I think been increased at 2.5, but rarely was an issue compared to poor design.
But note, that pool is shared by cron triggered rules and by some bindings with scheduled tasks like Astro.
statements waiting for their expiry at the same time.
This morning a rule started via the iphone app was running a rule that turns on a motor via MQTT, waits for a few seconds, then turns it off again before waiting again. The OFF part was delayed for several seconds, before starting that rule I’d started another rule with several timers in it. Yesterday a rule that does something else after a delay was delayed for many minutes before running, in that case its input came via MQTT, that produced an item update after a timer, and its output was via a sendHttpGetRequest created by a rule responding to the item update.
Logically my problem could be down to MQTT delays or Timer delays as this mornings delayed rule was running both, and as it was the first time I’d operated both rules sequentially I’m suspecting the timers.
There is a limit to how many can be actively running at the same time. You can have up to five event triggered Rules actively running at the same time. You can in OH 2.5 have up to ten Timers or time triggered Rules running at the same time.
But it’s important to understand that a Timer that is waiting to run is not consuming a thread. Only those who are actively executing code are consuming a thread. So when you say “run[ing] concurrently”, do you mean a bunch of Timers scheduled, or do you actually mean a bunch that are executing at the same time?
If the former, the answer is no. If the latter, the answer is yes, in 2.5 it’s 10. In 2.4 that number was 2.
Is it actually waiting (i.e. Thread::sleep or a while loop) or do you reschedule or set another Timer? If it’s the former, one of those ten threads will be consumed during the wait. If the latter than running out of threads isn’t the problem.
You can add logging to your Rules and Timers and compare when the MQTT event comes in in events.log with when the Rules trigger and then when the Timers run. You can use something like MQTT Explorer to see when the broker actually receives the message and compare that time to the logs as well.
The rule that failed, and today worked perfectly has many timers that are triggered by each other to sequence a set of curtains. Perhaps its time to rewrite with a single timer, its grown somewhat since I first created it. Since then I’ve added more things and more timers . Currently it runs something like this:
var Timer Timer1
var Timer Timer2
var Timer Timer3
rule "timer stuff"
when Item MyThing changed then {
Motor.sendCommand(ON)
Timer1 = createTimer(now.plusSeconds(15))[|
Motor.sendCommand(OFF)
Timer2 = createTimer(now.plusSeconds(45))[|
Motor.sendCommand(ON)
Timer3 = createTimer(now.plusSeconds(15))[|
Motor.sendCommand(OFF)
]
]
}
end
Could I just use one timer for that lot? I originally wrote it with Thread::sleep commands and had to hurriedly remove them when I ran into the rules stalled problem a long time ago. If its worthwhile having a rewrite can you point me to a good source?
Thanks, that’s an elegant solution! I’ll rewrite the rule next week. Before I do that I’ll see if the original problem reappears. I’ve been doing a lot of changes on the system recently so I’ll let the dust settle before I do any more changes. It seems from the helpful information on this thread that concurrently waiting timers is unlikely the problem.
