- Platform information:
Docker image openhab:2.2
I have copied the pattern (https://docs.openhab.org/configuration/rules-dsl.html#concurrency-guard) of using locks in rules as I am updating multiple numbers and need the updates to be protected by a lock. the logic in the code is easier to write if we validate the conditions first and return if the conditions are not met. I’ve noticed that if I return from a rule the finally block is not executed. For locks this is bad and stops the rules associated with the lock from executing.
I have reproduced with the simplest config I could find.
Test.items:
Switch testswitch1
Test.rules:
import java.util.concurrent.locks.ReentrantLock
var ReentrantLock lock = new ReentrantLock()
rule "Test Lock unlock"
when
Item testswitch1 changed
then
logInfo("Test","TRYLOCKED")
lock.lock()
logInfo("Test","LOCKED")
try {
logInfo("Test","RETURN")
return
} catch(Throwable t) {
lock.unlock()
logInfo("Test","catch:UNLOCKED")
} finally{
lock.unlock()
logInfo("Test","finally:UNLOCKED")
}
end
and a simple sitemap to toggle the switch:
sitemap default label="Home"
{
Default item=testswitch1 label="Amazing button"
}
If you toggle the switch you see the following in the logs and never see UNLOCKED
printed
2018-03-04 18:34:49.686 [DEBUG] [ntime.internal.engine.RuleEngineImpl] - Executing rule 'Test Lock unlock'
2018-03-04 18:34:49.788 [INFO ] [.eclipse.smarthome.model.script.Test] - TRYLOCKED
2018-03-04 18:34:49.791 [INFO ] [.eclipse.smarthome.model.script.Test] - LOCKED
2018-03-04 18:34:49.793 [INFO ] [.eclipse.smarthome.model.script.Test] - RETURN
Should this unlock the lock? Is this a bug or am I doing something stupid?
Thanks
Garth