Inconsistent logging


(Kelvin) #1

Current context is a LAN service manager / device handler app, but I have seen this in a pure app scenario as well.
I noticed that if I am doing heavy logging, I seem to “miss” some logs. Other times, they will show up so I know the code is not taking an exception.
Also, once I load devices, the device handler logging seems to work but the LAN service manager logging stops altogether.
Since there is no debugger, logging is pretty critical or development of any non-trivial stuff becomes fairly haphazard, at best.

Anyone else notice this or have a solution? I’m using log.debug, log.trace, log.warn


(Convinced ST will never be unbroken…) #2

Yeah, I’ve noticed it. Sometimes missing entries, other times they are displayed out of sequence, and other times they go AWOL altogether (as does the entire simulator from time to time). When this happens, reloading the page or restarting the browser clears things up as best as possible.

But for anyone not intimately familiar with Java and Groovy (and have to T&E some functions/commands to get the desired result) it can be REALLY frustrating.


(Alex) #3

Logging and simulator was too unreliable for me too. I eventually run out of time and patience writing a service manager.


(swanny) #4

Here are a few things I’ve noticed when trying to write a service manager:

If you call a parent function from the child, you don’t see any logging that the parent would have sent. The same for the opposite scenario. I’ve seen the out of order logging as well. I am pretty sure these are both artifacts of the way the threading of the various event processing is handled. The second one is very common in multithreaded logging environments. Many logging environments actually have a process number and/or name associated with each line similar to what ST does with it’s various SmartApps and devices but would also include a subprocess number. As far as lines going missing, I wouldn’t be surprised if there is a maximum amount of output that can be sent from one execution of a process.

Thread synchronization methods don’t seem to be any accessible (probably for performance reasons) which means you can’t wait in a process for a variable to be updated in another process. From what I’ve seen once you read a variable in a process (call it A), you cannot get a new value updated by process B until the next execution of A. I think all notions of volatile and thread synchronization primitives are disabled. Events or scheduled processes basically handle this function although they can be more complicated to deal with as your SmartApp gets more complex.

I’ve spent a good amount of trial and error effort in debugging these interactions and it’s not easy. One of the things I try is to periodically uninstall my SmartApp and device type and restart to make sure it’s cleaned up. I also use the main log window and reselect “Log” when I’m not seeing data to make sure it’s still connected to the server correctly. Some of it’s like voodoo though.

All of this is trial and error speculation really, so please anyone correct me if I’m mistaken. :smile:


(Reed Taylor) #5

I know this is an aging thread, but I’m reviving it in case anyone else is seeing this:

I have several smartapps that I’ve written or modified that simply do not do any logging outside the simulator, or they produce very odd, sparse logging. Some of them have side-effects (i.e. turning stuff on and off) so that I can tell they are indeed running, but none of the actual log calls I make in the app are reflected in the logs.

Oddly, on the simulator it works properly, both in the sim and (if I install it on my “real” hub from the simulator) in the “real” logs. Has anyone else seen anything like this? Any suggestions on how to make it start working again?


(Beckwith) #6

@schmedlock

This was brought up in the recent developer discussion session. It is a known issue where logs are occasionally dropped under heavy loads and/or circumstances. The suggested temporary fix is to truncate logs instead of dropping them. Don’t know if or when such a workaround is put into place nor if there is a better long term fix.

Contact support for more.