Rule triggers twice on received update via mqtt

I expect Rich will enlighten us in a minute, but I am specifically talking multiple starts of the same rule, I thought that got queued one at a time in NGRE.

You are correctā€¦ only one instance of a rule can run at a time. This eliminates the need for locks. If this causes an issue, have the rule spawn up a new thread. In Jython, I recommend thread.start_new_thread. Here is some discussionā€¦

1 Like

Thatā€™s why global lambdas in rules DSL are so dangerous. When two rules call a global lambda at the same time, they are not running two separate copies of the function, as is usually the case. They are actually running the exact same function at the same time. That means, for example, if you set a variable at the top of the lambda it might become overwritten by the second concurrent call by the time you get down to the parts of the lambda that use the variable, causing all sorts of havoc.

Also note, when OH 3 comes out the same rule is prevented from running more than one instance at a time I think even for Rules DSL as I understand it. So this problem will become somewhat ameliorated, at least for those cases where the global variable is only accessed from one rule. It doesnā€™t help if you have two or more rules accessing the same global variable though.

Yeh, itā€™s all an aside really, but with further thought this -
rulecounter = rulecounter + 1
is problematic in this case of highly parallel rules. Because itā€™s not a single operation. Rule A reads the variable value, and before it has time to do its sums and write the new value back, along comes Rule B and reads the same old value.
ā€˜rulecounter++ā€™
might work better, looking like a single operation ā€¦ but I wouldnā€™t be surprised if it had exactly the same problem behind the scenes.