Multi threaded access requested by thread but is not allowed for language(s) appears again after upgrade to OH4.2

Setup, Configuration and Use Scripts & Rules
1
  • Platform information:
    • openHAB version: 4.2.2 Docker Image
  • Issue of the topic:
    Hi,
    some time ago I had troubles with the following error
Failed to execute rule 'LueftungssteuerungBadOben': Failed to execute action: 5(Multi threaded access requested by thread Thread[OH-rule-LueftungssteuerungBadOben-1,5,main] but is not allowed for language(s) js.)

but it has been fixed when I changed my code from using Timers to ThreadsafeTimers. After upgrading from OH4.1.1 to OH4.2.2 the error now returns occasionally. Is there something that has changed in OH4.2 regarding ThreadsafeTimers?

Code Example.

var telegramAction = actions.get("telegram","telegram:telegramBot:XXX");
var now = time.ZonedDateTime.now();

var timerSendTelegramGenerator = function (arg) {
  console.debug('timerSendTelegramThingOffline start: ' + arg);
  return function() {
    console.debug('timerSendTelegramThingOffline.function start: ' + arg);
    if(things.getThing(arg).status === "OFFLINE") {
      console.debug("telegramAction.sendTelegram(" + arg + ");");
      telegramAction.sendTelegram("OpenHAB4 prod: " +arg + " triggered!");
    }
    cache.private.remove(arg);
    console.debug('timerSendTelegramThingOffline.function finished');
  }
}
...
cache.private.put(getThing(event.thingUID.toString(), ThreadsafeTimers.createTimer(event.thingUID.toString(), now.plusMinutes(16), timerSendTelegramGenerator(event.thingUID.toString()))));

Thank you,
Markus

2

Nothing beyond the fact that all Timers created through the openhab-js library are ThreadSafeTimers now so there’s no need to mess with that internal class in your rules. All timers are thread safe now.

However, I too on occasion see the exception. Usually it’s when a given rule creates Timers and there are lots and lots a fast triggers to that rule. The access to the context has a lock so it shouldn’t happen even then but there is clearly something that’s bypassing the lock. I can’t make it happen with enough regularity to gather the information to file an issue though.

There might be something happening here with the Telegram action which isn’t locked perhaps.

Is this rule being triggered rapidly? Does it take some time for the Telegram action to complete, enough time where a second timer might want to run while the previous timer is running?

3

Running a rule from another rule is bypassing the locking mechanism IIRC …

4

Correct and I’m pretty sure that’s what is happening when I see the exception. But that’s not happening here nor on Blockly producing multi threaded access which is another reason why I’m not sure what I’ve seen is relevant to what they are reporting.

I’ve also toyed with experimenting with adding some sort of locking to runRule() too (current though is adding a function to OHRT that uses the shared cache to store semiphores or rentrant locks by called ruleUID. I don’t know how feasible they would be to add to openhab-js though. It probably would need to be something implemented in core I would think to do it properly, but since JS Scripting is the only one with a problem does that make any sense.

But either way, calling another rule isn’t something that is causing the problem here and there is some light evidence that there might be a regression on the locking as both threads report it worked in 4.1 and not 4.2.