Has anyone noticed lately that exceptions thrown from a Library code greatly slow down the hub?
I had to reboot my old C-7 hub in Safe mode several times in the past week ... 
Buggy code resulting in exceptions thrown may happen during the development... But what I observe now didn't happen in the past. I mean exceptions that happen with 10 or more seconds apart, not thrown every second ... I am unable to open the code in the HE inbuilt editor.
I experience this problem only with library files. Exceptions thrown from the main driver code are handled normally.
From what I've read here, libraries aren't really a "thing". Under the hood HE just slaps them together onto anything that uses them by appending the library to the driver/app and then using that combined code. From an execution standpoint, library code doesn't exist. It's doing the exact same thing as if you manually just did a select-all/copy/paste of the library code into your driver.
You can actually see this in the logs, where things that use libraries spit out useless line numbers, with the line number not lining up with where the actual issue is.
Now, if that's not how things actually work, maybe that explains some of the issues people have with some of my apps. If they're getting an exception on Sonos Advanced that is in the library code (and there's a LOT of code for them in libraries), then maybe that's part of what causes people to have hub lockups.
I've still got my bet on whatever issue they resolved in 128 patch not actually being completely resolved. They patched an issue where a large number of rapid events would lock up the hub, and Sonos Advanced certainly does just that, possibly emitting 100+ events nearly simultaneously when tracks change with a large number of speakers playing.
1 Like
I am now in Safe Mode.
I have a lot of custom drivers accumulated over the past years... I exported the list to excel and the count is 338 drivers! 
The drivers page loads relatively fast on my slow C-7 dev hub in just 3 seconds.
I have counted 39 libraries -> the HE Libraries web page needs 29 seconds only to list them!
The slow listing of the libraries HE web page may not be directly related to the exceptions handling slow-down, but it is a strange fact also. (No custom code is executed in Safe Mode!)
I await a new C-8 Pro hub in the next few days. I was going to migrate the old C-7 to the new C-8 to keep all my stuff on the new hub, but now I think it will be much safer to start from scratch.
I use the Download Code button to find the actual line number in Notepad++
1 Like
I've never clicked on that... I figured it just downloaded the code displayed in the text editor on screen, and since my code all already lives on my Mac, I've never had a reason to download it. No idea it downloaded the merged "complete" driver like that... that's fantastic for figuring out where some errors are when using libraries! Thanks.
1 Like
I was missing a closing bracket } in one of the library methods.
I think the following happens:
- When I publish the modified library code, it is simply saved on the HE hub, No parsing / compiling ( I use the term 'compilation' although it may not be the correct one? )
- HE detects that the driver that depends on this library code is modified and tries to 'compile' the main code together with the library code.
- as the library code compilation throws an error because of the missing bracket, the compilation process fails.
- upon next driver call (?), the unsuccessful compilation process starts again
- The above process is repeated until the broken library groovy code is fixed and the next compilation succeeds.
(the code with all the libraries included is 3791 lines)
?
I can NOT publish a broken main driver code, but I can publish a broken library groovy code.
1 Like
Ah! Yeah. That'll cause issues.
Do you use the VS Code Hubitat add-on? I do. What I also do is ALWAYS follow every publish on a library with a quick publish command for any driver/app that uses it. Doesn't matter which, or even if it's changed. If there's an error in the library, then the publish command for something that uses it will complain. That way I can quickly find silly issues like a missing } in my library.
Is it ideal to need to publish a driver/app immediately after publishing a library just to catch errors in the library? Nope. But it works.
Same should work if you just open/save an app/driver in the Hubitat UI after saving a library, just slower and with more hassle. The VS Code add-on is pretty nice.
1 Like
Yes, I am using the VS Code Hubitat add-on, it is a great tool !
Thank you for the hint - I will use it from now on!
Yeah, it doesn't stop you from pushing a broken library... but at least it means the time between pushing said broken library and noticing it's broken is a few seconds rather than an indeterminate amount of time.
It is not the use of the VS Code tool - I replicated the same problem when I used the HE inbuilt driver editor.
This time, I had the missing bracket already restored and the mouse pointer over the Save button in the HE driver editor!
This test result may be interesting ( the ' Failed to acquire semaphore for method parse within 120 seconds ''error :
Yeah, it's any time you update a library. I think it's a result of the 'it just gets appended to the driver code blindly' thing that library code does in the background.
Driver 4848... that a Sonos speaker? I'm about 95% sure there's a HE platform issue that my app is running into that causes that. There's not really a whole lot of other apps/drivers on HE that process quite so much incoming data, and of the few that do, such as the HA-HE bridge app or the InfluxDB driver, it's just a single app/driver running. Sonos Advanced churns through a ton of incoming data and does it across a bunch of drivers basically simultaneously. I have no control over how/what/when the speakers send data, it's all or nothing, so I can't 'turn down' what it tries to process.
Based on the notes on the 128 patch recently I'm thinking that maybe whatever that issue was that they fixed isn't completely fixed.
1 Like
No, device 4848 is using my driver where I intentionally deleted the closing curly bracket for the test.
You are facing much more serious challenges with Sonos than my worries with some spammy Tuya devices.... My solution was easy: sacrificing the processing speed for the stability, using singleThreaded: true. .... and complex and ugly-looking state machines code.
