Memory Leak MI IO?

hi @marcel_verpaalen

could there be a memory leak in the recent version?

06:27:27.010 [ERROR] [internal.DiscoveryServiceRegistryImpl] - Cannot notify the DiscoveryListener org.eclipse.smarthome.config.discovery.internal.PersistentInbox on Thing discovered event!
java.lang.IllegalStateException: Timer already cancelled.
	at java.util.Timer.sched(Timer.java:397) ~[?:?]
	at java.util.Timer.schedule(Timer.java:193) ~[?:?]
	at org.eclipse.smarthome.storage.json.internal.JsonStorage.deferredCommit(JsonStorage.java:340) ~[?:?]
	at org.eclipse.smarthome.storage.json.internal.JsonStorage.put(JsonStorage.java:138) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.PersistentInbox.add(PersistentInbox.java:198) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.PersistentInbox.thingDiscovered(PersistentInbox.java:345) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl$1.run(DiscoveryServiceRegistryImpl.java:268) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl$1.run(DiscoveryServiceRegistryImpl.java:1) ~[?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.thingDiscovered(DiscoveryServiceRegistryImpl.java:265) ~[?:?]
	at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.thingDiscovered(AbstractDiscoveryService.java:280) ~[?:?]
	at org.openhab.binding.miio.internal.discovery.MiIoDiscovery.discovered(MiIoDiscovery.java:150) ~[?:?]
	at org.openhab.binding.miio.internal.discovery.MiIoDiscovery.access$1(MiIoDiscovery.java:119) ~[?:?]
	at org.openhab.binding.miio.internal.discovery.MiIoDiscovery$ReceiverThread.lambda$0(MiIoDiscovery.java:286) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:745) [?:?]
06:28:07.095 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1ff6f51' takes more than 5000ms.
06:27:53.735 [INFO ] [smarthome.event.ItemStateChangedEvent] - LOCALWEATHER_windir changed from 224 to 243
06:30:14.140 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@391d3d' takes more than 5000ms.
06:33:01.137 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@3c26bb' takes more than 5000ms.
06:37:46.534 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1ff6f51' takes more than 5000ms.
06:40:38.386 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@391d3d' takes more than 5000ms.
Exception in thread "pool-2339-thread-1" java.lang.OutOfMemoryError: Java heap space07:13:18.242 [WARN ] [ome.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@5506dd' takes more than 5000ms.

Exception in thread "Mi IO MessageSenderThread" java.lang.OutOfMemoryError: Java heap space

I don’t think anything changed recently in the miio code…
But indeed this needs to be monitored to understand what’s behind it

Was this a onetime event, or you see this behavior more often?

for the moment it seems like one time event

I did read most of the things … also my MI things

Can it be related it always finds the roborock s50 with 2 entries in auto discovery?

this is expected behavior… there are actually 2 independent methods for discovering devices.
So far I was not able to avoid the double entries in a good way

Hi,

On my machine the leaking started as well:

I do not think i have updated neither openhab (running on a Raspberry PI) nor the Mi IO - Plugin.
But i do apt update && apt upgade regularly. So maybe this has something to do with the runtime envrironment?

I do use the Oracle JDK:

java version “1.8.0_201”
Java™ SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot™ Client VM (build 25.201-b09, mixed mode)

Any idea?

Kind regards and thanks a lot for the great plugin,

Chris

Edit: Just realized that this thread is about memory leaking, not thread leaking.
Should i open a new thread?

I think this is related to

I’m still in the dark on the cause of it…
Are you using text config or the thing via paperUI discovery ?

Hi,

I´m using text config only on OpenHAb stable / 2.4.0.
It used to work for quiet a few months without any issues.
Then OpenHab stopped responding and needs to be restarted. It keeps on doing so until now.
After every two days or so the number of Mi IO MessageSenderThreads is within several thousands.
Openhab then runs out of memory giving OOM-Exception:

java.lang.OutOfMemoryError: unable to create new native thread

I made a backup of my config and reinstalled OpenHab freshly - no effect. It runs OOM, having high CPU load and thousands of these threads above.

Can i help with anything?

Greets,

Chris

I guess you have in your thing file you have not defined your deviceId
Can you please add the deviceId for your device (you can see it in the parperUI screen).
I expect that will solve your issue. (it is mandatory config in the current version)

1 Like

Marcel,

Your are totally right. Adding the deviceId in the .things-File did the trick.
Just one Mi IO MessageSenderThread lives happily.
The moment i remove the deviceId from the .thing-Config, new Mi IO MessageSenderThreads are spawned (and start to sum up till OOM).

I wonder how you found this one. Thank you very much for your precise help!

Kind regards,
Chris