Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

Stop whole OH2 event processing after Chromecast TV disconnection #4724

Closed
anklimov opened this issue Dec 11, 2017 · 2 comments
Closed

Stop whole OH2 event processing after Chromecast TV disconnection #4724

anklimov opened this issue Dec 11, 2017 · 2 comments

Comments

@anklimov
Copy link

anklimov commented Dec 11, 2017

Build #1106

This issue is very similar with previous fixed "Blacklisting ServiceReference " but behavior is slightly changed after commit 4655 (#4655)

It looks like timeout in single bundle may still block whole event processing

2017-12-11 10:00:38.178 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. Thread 'safeCall-2' (133) is in state 'BLOCKED'
        at su.litvak.chromecast.api.v2.ChromeCast.disconnect(ChromeCast.java:138)
        at org.openhab.binding.chromecast.handler.ChromecastHandler$Coordinator.destroy(ChromecastHandler.java:259)
        at org.openhab.binding.chromecast.handler.ChromecastHandler.dispose(ChromecastHandler.java:139)
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:226)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...
2017-12-11 10:11:28.170 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. Thread 'safeCall-1' (132) is in state 'BLOCKED'
        at su.litvak.chromecast.api.v2.ChromeCast.disconnect(ChromeCast.java:138)
        at org.openhab.binding.chromecast.handler.ChromecastHandler$Coordinator.destroy(ChromecastHandler.java:259)
        at org.openhab.binding.chromecast.handler.ChromecastHandler.dispose(ChromecastHandler.java:139)
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:226)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...
2017-12-11 10:15:02.802 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. Thread 'safeCall-3' (136) is in state 'BLOCKED'
        at su.litvak.chromecast.api.v2.ChromeCast.disconnect(ChromeCast.java:138)
        at org.openhab.binding.chromecast.handler.ChromecastHandler$Coordinator.destroy(ChromecastHandler.java:259)
        at org.openhab.binding.chromecast.handler.ChromecastHandler.dispose(ChromecastHandler.java:139)
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:226)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...
2017-12-11 10:29:13.188 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. The task was still queued.
2017-12-11 11:05:53.694 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. The task was still queued.
2017-12-11 11:05:58.746 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. The task was still queued.
2017-12-11 11:07:32.863 [WARN ] [nal.common.AbstractInvocationHandler] - Timeout of 5000ms exceeded while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.bind
ing.chromecast.handler.ChromecastHandler@7ae2c143'. The task was still queued.
@kaikreuzer
Copy link
Contributor

I cannot see from this log that the whole event processing is blocked.
It is correct that single handlers can block single event threads, but the framework now assures that a handler then won't be called by any other threads.

The log shows that the framework correctly blames a certain handler implementation for not working properly.

@kaikreuzer
Copy link
Contributor

(btw, please try to use a more recent build than 1106 as I think that the final implementation came slightly later)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants