Ok, so I took a look at the log you posted in the zwave repo…
2018-11-17 14:30:17.864 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2018-11-17 14:30:17.866 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:512.
2018-11-17 14:30:17.867 [DEBUG] [zwave.handler.ZWaveControllerHandler] - No network key set by user - using secure random value.
2018-11-17 14:30:22.861 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'zwave:serial_zstick:512' takes more than 5000ms.
This is a little strange. The controller handler decides to generate a network key. Five seconds later, the framework complains about the handler initialization taking more than 5 seconds.
This is a bit of a stretch, but I’m curious what kind of hardware you’re running. SecureRandom.getInstanceStrong() can be very slow on some platforms. It’s not out of the question that it could take more than 5 seconds.
@chris I don’t see anything else in ZWaveControllerHandler.initialize that could cause it to take more than 5 seconds to complete. WDYT?
I’m not sure - I’ve never benchmarked this - I would be a little surprised if it was taking 5 seconds, although if there are a lot of other threads also happening at the same time during startup, then maybe it’s possible.
If it was that though, then starting the binding after system init might help.
@chris The fact that the key was empty suggests pretty strongly that the call to SecureRandom.getInstanceStrong() did take longer than 5 seconds. Otherwise, had the call returned, it would’ve been saved in the config. Right?
I don’t think there’s anything to do about this now, as this is the only report there’s been on the handler initialization taking too long.
@mhilbush thanks for testing and researching this issue, I suspect you are 100% correct in blaming SecureRandom.getInstanceStrong().
I suspect the 5+ second time will only occur on systems which 1) do not have a built in hardware RNG (IIRC the ras pi even has this now) OR 2) those which are virtualized in such a manner that that the underlying hardware RNG cannot be accessed properly for whatever reason (not implemented by the container, bug, etc).
@hardoverflow I have implemented a possible fix but I am unable to reproduce this behavior on my machines here. Would be able to test out this build to see if it resolves the issue?
Thanks everyone for tracking this down and the details provided.
i installed your build. It actually didn’t fix my issue but installing haveged and starting it fixed the problem. But now everything is reacting very slow like 1 to 2 seconds.
I’am running a Intel NUC on Debian 9 with Openhab 2.4.0 M6.