-
Notifications
You must be signed in to change notification settings - Fork 784
Starred interaction on config and rules changes #4716
Comments
Hi @mstormi did you already have a discussion about this in the community forum? Please provide the link. |
Just for clarification: Is this a RPi specific behavior or do we see sluggish rule parsing also on x86 PCs (then maybe not 3 minutes, but 10 seconds, but still "too slow and blocking")? |
Well I've been having this problem for a long time, on RPi2 but also on my today's RPi3 based on openHABian, on various kernel, JVM and OH versions. My current setup provides multi-processing for sure. I agree it's the right approach to 'work up the stack' but we quickly arrive at the code layer. Let's make it clear again: While the system behavior from a user point of view is 'sluggish', this is not because of lack of processing ressources to be available at that moment in time. It is because the system processes updated rules and does NOT process API input while doing the former. |
My feeling is that all this is unfortunately right. |
Using your example file in my openHAB IDE:
So this file takes 400ms to parse on my Mac. This does not seem to be any exceptionally long time, does it? |
Sure, but what would that tell you ? I feel you're still missing the point. If you had used the UI within these 400ms, you would have noticed it was blocked. Now on a slow machine with a large rule, these 400ms could become 40 seconds or more, and that's an annoying lag then. |
My point is that parsing should never take longer than a very few seconds. And if this is the case, it does not matter if access to items and sitemaps is blocked for that moment. If you had to restart the runtime after a configuration file change, the situation would be worse... I'd rather want to fight the root cause and not the symptoms. |
me too. But while yes, parsing should be faster, that's just an 'accelerator' but it isn't the root. rules and items files still can be large and machines slow, you can never know how long that'll take in the end if it's not your ruleset running on your Mac. |
Here's a data point from a rule that has 1395 lines. Looks like it took almost 12 seconds. This is on a 1.6 GHz 4-core Intel Celeron with 8 GB 1600 MHz RAM. The file contains a bunch of lambdas and rules.
I will add that I have not observed the behavior with the UI blocking as described above. I will try to test for that while the rule file is being processed. Hopefully my fingers will have the dexterity needed to do this. :-) |
I can confirm that Basic UI blocks during the 12 seconds that my rule is loading. By blocks, I mean that if I click on an object, such as to go to another frame, the new frame doesn't load until the rule has finished processing. |
Ok then, let's define this issue to look at the blocking then. As a solution, the sitemap provider should probably best keep an internal copy of the models for itself. I would not dare to relax the synchronization on the resource set as I remember that there were many issues in that spot when doing concurrent accesses. |
I see no issue with dashboard, HABpanel, and PaperUI. I'll check the Android app shortly. |
Confirming that the Android app blocks. |
Thanks for checking, good to hear that my analysis seems to be correct then. |
FWIW, I've just encountered a state where Basic UI was blocked again while java was at 100% doing whatever (I did NOT change any DSL files this time, so it must have been doing something different but I don't know what that was) . |
Is this supposed to fix the 'UI hangs on processing rules' ? |
When switching frames in Basic UI there are other interactions with the ModelRepository: during frame rendering the category for a widget is calculated. In case the icon is not set directly in the widget (i.e. in the sitemap) the attached item is queried to provide an item. This will access the item model from the GenericItemUIProvider which in turn is loaded from the ModelRepository. |
The fix just gets the item from the also present ItemRegistry and removes the ModelRepository from the GenricItemUIProvider. This fixes it for me. |
Just installed OH #1194 (to include yesterday's ESH update) and yes, looks like it is fixed now. |
1194 looks good from here. Yay! |
Now while this one seems to be fixed, I've encountered a similar thing on rule execution: |
@mstormi, thanks for the ongoing reports. From the code I can see that |
I created #5186 to further track this issue. |
Whenever I change an items or rules file, to process this update in OH can take up to 2 or 3 minutes (for a 1k lines rules file on a Pi2). java is runnning at 100% CPU (i.e. 1 core@100%, but 3 idle cores).
Meanwhile, the interaction via REST or Web UI is apparently HALTED until the current file is processed.
As requested by @kaikreuzer, here's a large rules file to help you reproduce it, but it happens on any rule und items file (re)load: it takes the API and UI to react exactly as long as it takes to process the updated file, UI comes back to life as soon as the 'refreshing xxx.rules' log entry shows up.
reloadtest.TXT
The text was updated successfully, but these errors were encountered: