Smarthome: Things remaining in INITIALIZING state at startup

[lolodomo]

With the last ESH/OH build (snapshot 1186), we have the comeback of things not initializing correctly at startup.
Most of bridge things (hue, netatmo, ...) remains in a INITIALIZING state.
I have nothing special logged.
The problem is at each startup.

The problem was introduced after the snapshot 1140.

[kaikreuzer]

I noticed the same on my setup that I just upgraded to 1186. Will try to debug.

[mhilbush]

I have nothing special logged.

While nothing is logged, I see messages in my log indicating that scheduled jobs are about to be started, but the jobs never start. See here

[mhilbush]

Confirming that build 1187 resolved the problem for me.

[kaikreuzer]

You are quick, it only just finished building!

[mhilbush]

I figured you might want some feedback before you went to bed. :-)

[kaikreuzer]

Much appreciated :-)
I can confirm that the problem is solved for me as well - so we should be allowed to have some good sleep now!

[lolodomo]

Thank you guys.

[afuechsel]

It is strange, that reverting back solved the issue. The implementation done in WrappedScheduledExecutorService is according to the example which can be found in the javadoc and does nothing special. At least on first sight. https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html#afterExecute-java.lang.Runnable-java.lang.Throwable-

[afuechsel]

Looking deeper I wonder, if this may cause the afterExecute to block:

java ((Future<?>) r).get();

What will happen, if the underlying future takes a little bit longer? Will blocking the afterExecute be a problem? Will a second get() invoked on the same future cause some problems?

According https://stackoverflow.com/questions/35366018/overriding-threadpoolexecutor-afterexecute-method-any-cons it will not cause problems...

Just some quick thoughts...

[kaikreuzer]

When debugging, the problem indeed was that the get() method blocked.
But note that this code comes directly from the official JavaDoc of afterExecute, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html#afterExecute-java.lang.Runnable-java.lang.Throwable-.

The weird thing is that the status of the task was 0 (=NEW) and not status >= NORMAL.

[afuechsel]

As https://stackoverflow.com/questions/35366018/overriding-threadpoolexecutor-afterexecute-method-any-cons states, get() should NOT block, as the method is called AFTER execution. But it looks weird. Even the official javadoc may have some flaws...

[afuechsel]

The long discussion here: https://stackoverflow.com/questions/2248131/handling-exceptions-from-java-executorservice-tasks suggests something like this:

java if (future.isDone()) { future.get(); }

[kaikreuzer]

This would filter out the cases where status=0, so it might help, yes.