Shelly Memory/Thread leak in 3.4M5

Hey there,
I wonder if somebody else has the same experience. With M5 my openhab install goes into a OOM issue after max 5 hour. Attaching JConsole cleary indicates a never ending growth of threats until it crashes. Removing the Shelly binding, the problem vanished.
Is that specific to my config, ~20 Shellies, or does somebody else sees the same?
Running openhabian on a raspi 4.

After 4 hours ~2500 threads in JConsole, most of them WebSocketClient

@markus7017 FYI, as you are the binding maintainer.

Which build are you using? there was a problem with Plus/Pro devices about 2 month ago. I never saw that with Gen1 devices. Please switch to the latest DEV build (see Shelly Binding thread).

I observed the issue on 3.4 M5. I now switched to build 3212 and will test. Thx!

Switched to build 3212, I still see the same grow of threads, roughly 1000 per hour. TRACE logs NullPointerExceptions:
2022-12-10 17:35:32.681 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellypro2pm-ec62608d99d0: Unable to refresh status: Unable to update status

java.lang.NullPointerException: null

at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.createRelayChannels(ShellyChannelDefinitions.java:350) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.createRelayChannels(ShellyRelayHandler.java:293) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.updateRelays(ShellyRelayHandler.java:337) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.updateDeviceStatus(ShellyRelayHandler.java:202) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.refreshStatus(ShellyBaseHandler.java:522) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

2022-12-10 17:35:33.100 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1pm-ba47ee: Unable to refresh status: Unable to update status

java.lang.IllegalArgumentException: Channel definition for sensors#input not found!
at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions$ChannelMap.get(ShellyChannelDefinitions.java:745) ~[?:?]
at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.getDefinition(ShellyChannelDefinitions.java:284) ~[?:?]
at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.addChannel(ShellyChannelDefinitions.java:559) ~[?:?]
at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.createRelayChannels(ShellyChannelDefinitions.java:347) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.createRelayChannels(ShellyRelayHandler.java:293) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.updateRelays(ShellyRelayHandler.java:337) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyRelayHandler.updateDeviceStatus(ShellyRelayHandler.java:202) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.refreshStatus(ShellyBaseHandler.java:522) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

I think I found my problem.
After I deleted all Shelly things the problem remained -growing number of threats. So I need to assume it happens in the discovery phase.
In one of the trace messages I saw a hint of:
.shelly.internal.api1.Shelly1HttpApi] - Energy Meter (shellyem3-244cab435976@192.168.0.106): API call returned exception
However, there is no shelly under x.x.x.106.
Checking the dns cache on the raspberry actually showed an old entry for x.x.x.106.
After flushing the dns cache and restart of the router, the number of threats are stable.

I hope this may help for someone may running into the same issue.