This is a really old thread and several of the people on this thread are not around any more. A lot has changed in OH in the three and a half years since this was published. In particular, in OH 2 for the Experimental Rule Engine, in OH 3 and OH 4 for the all rules languages/add-ons, rule triggers are queued. Any rule can have only one instance running at a time with subsequent rules queued up automatically.
There really isn’t even a need for a queue for your use case anymore (the original post would still need to use a queue though as it want to collect the messages over a time and then read them off which is a different use case).
Why not trigger the rule with received command?
You’d need to show the rule because what you are seeing might be a result of something else (e.g. a TOCTOU where the Item state changes between the time where the rule was triggered and you attempt to use the Item’s state, in which case you should use the newState implicit variable instead which has the state of the Item that triggered the rule regardless of what state the Item is currently in.
Given the state of the upstream Jython library and the fact that there’s no one left supporting the Jython add-on in OH, I cannot recommend starting any new rules development using Jython. Anything else will be a better choice right now.
I don’t think so because the way that OH 3+ works you shouldn’t be seeing this behavior. But it could be related to how you’ve implemented it. Even with a received update trigger, you should not be losing any of the messages.
If you did need a queue for other reasons, pretty much all of the rules languages have one built in. JavaScript does not but you can use my Gatekeeper as a queue if you use 0 as the delay between commands. You could even use that from Blockly but you’ll have to use an inline block to do it.