Too much time before a Sonos thing becomes definitively ONLINE

Interesting. I’m not calling that code anymore so I’m not sure why it would be that. That said, stranger things have happened. If you’re getting that message regularly, remove the two threadpool configs and see if it is still happening. Removing the configs puts it back to normal.

Error occured again, so I removed
org.jupnp:asyncThreadPool=false
org.jupnp:mainThreadPool=false

I’ll keep you updated if error will occure again

That would mean that thread pools are more adapted to small hardware.

I use a raspberry 3b with openhabian

So that’s definitely true. More because of memory usage than actual thread count. The problem is when you need more threads but don’t have the memory to let them grow. Then you have to really tune the threadpool. My OH has 8GB of RAM so I’m fine letting them free build. We may need to tune the Java memory in addition to help this. That said, im tracking other posts about the memory errors so this could also be a bug.

I dont have a 3 to test with. I could load up a 4GB Pi4 and test if needed at some point.

—removed old post—

EDIT:

Please add the following to the log xml config.

        <Logger additivity="false" level="TRACE" name="org.jupnp.registry">
                <AppenderRef ref="JUPNP"/>
        </Logger>

I was looking at my logs and I see huge bursts of upnp-remote threads being created every few minutes. When I see that, I get a whole bunch of messages like:

2021-02-04 15:38:56.135 [TRACE] [org.jupnp.registry.Registry         ] - Updating root device of embedded: (RemoteDevice) Identity: (RemoteDeviceIdentity) UDN: uuid:f4dba198-5a98-1a4b-0080-0005cdf9dcee, Descriptor: http://REDACTED.191:60006/upnp/desc/aios_device/aios_device.xml, Root: false
2021-02-04 15:38:56.135 [TRACE] [org.jupnp.registry.Registry         ] - Updating expiration of: (RemoteDevice) Identity: (RemoteDeviceIdentity) UDN: uuid:9565750f-8c73-1b19-0080-0005cdf9dcee, Descriptor: http://REDACTED.191:60006/upnp/desc/aios_device/aios_device.xml, Root: true
2021-02-04 15:38:56.135 [TRACE] [org.jupnp.registry.Registry         ] - Remote device updated, calling listeners: (RemoteDevice) Identity: (RemoteDeviceIdentity) UDN: uuid:9565750f-8c73-1b19-0080-0005cdf9dcee, Descriptor: http://REDACTED.191:60006/upnp/desc/aios_device/aios_device.xml, Root: true

The funny part of it is that the messages are coming from my Denon receiver, which doesn’t use UPnP at all (from the perspective of OH). It’s a telnet based binding.

My overall theory about all of this is that the majority of problems people are facing are being caused by UPnP devices on the network that you’re likely not even using in OH. JuPnP keeps a registry of all of these devices and still processes them. When that happens, huge spikes in thread usage happen. If this is the case, I think I can probably use a threadpool to specifically handle the registry while letting other things free spin. It may be best of both worlds.

EDIT 2:
More better. I’ve broken the remote listener service off to be directly configurable for a pool while leaving the rest of the async pieces also configurable. Please pull a new jar from

You now have several options to tweak/tune depending on your system. This is what I’m set to right now.

org.jupnp:retryAfterSeconds=10

org.jupnp:asyncThreadPoolSize=60
org.jupnp:threadPoolSize=30
org.jupnp:remoteThreadPoolSize=60

org.jupnp:asyncThreadPool=false
org.jupnp:mainThreadPool=false
org.jupnp:remoteThreadPool=false

In the case above of the OutOfMemoryError, you may want to consider setting remoteThreadPool to true (or just don’t include it) and then adjust remoteThreadPoolSize. This should contain the remote messages to a threadpool so they can’t spin out of control and burn through the memory while letting the rest of the async services execute as needed. The remote registry pieces seem to be the most bursty which could definitely cause problems on lower end systems.

EDIT 3: I missed one thread. Updated now to release ending 8392ab9. Jar link above updated.

1 Like

I also have the binding and can confirm such messages on my system, too:

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
        at java.lang.Thread.start0(Native Method) ~[?:?]
        at java.lang.Thread.start(Thread.java:803) ~[?:?]
        at org.openhab.binding.denonmarantz.internal.connector.telnet.DenonMarantzTelnetConnector.connect(DenonMarantzTelnetConnector.java:74) ~[?:?]
        at org.openhab.binding.denonmarantz.internal.handler.DenonMarantzHandler.createConnection(DenonMarantzHandler.java:326) ~[?:?]

increase or decrease?

I have installed the new jar, thanks for that!
I will report if something happens…

That’s the mystery! It needs to be big enough to not choke the system but small enough to not blow the ram out. You’re going to have to play with it. I’d say don’t go much higher than 30 on your system if even that. Maybe start at 15 with the other two set to false. If that still causes issues, also set threadPoolSize to 15 and mainThreadPool to true to see if it helps.

The async pool is the one that “seems to be the culprit” for the devices going offline randomly. That one needs to be the most free from what I can tell.

Due to the data loss of the forum, I post my current status:

The new jar solves my issue (poweroff/on), it takes about 30 sec till the device is online again - measured from power plug in till it plays music

These short “one second” absents happen one or two times a day.

My setup:
org.jupnp:retryAfterSeconds=10

org.jupnp:asyncThreadPoolSize=60
org.jupnp:threadPoolSize=30
org.jupnp:remoteThreadPoolSize=60

org.jupnp:asyncThreadPool=false
org.jupnp:mainThreadPool=false
org.jupnp:remoteThreadPool=true

Hi @morph166955, just ckecked github issue above, am I right there is still development regarding this issue? It is not yet merged in official jupnp lib?
Thanks for info!

Yes that is correct. I just commented on the two PRs. Unfortunately my dev environment is completely down right now so I can’t contribute the commit Kai is requesting to close out the thread PR. We have a path, just don’t have the ability to write the code.

Thanks for your effort!

Will the individual setup (eg org.jupnp:retryAfterSeconds) be still needed with the official release?

Kai has committed a few of the PRs. One left to go and I believe it just needs a small change before it’s merged. retryAfterSeconds always existed (it was/is set to 10 mins), this just makes it flexible via config. You also now have timeoutSeconds and retryIterations. These settings will hopefully help the system recover a device without it ever going offline. Once the last PR is committed then that should fix the issues I’ve been seeing with the thread pools getting jammed up randomly and losing replies. So hopefully, once all of those are committed, and we update the jupnp version on OH, then this should all be behind us.

1 Like

For those watching - upgrade to JUPnP 2.6.0 by kaikreuzer · Pull Request #2396 · openhab/openhab-core · GitHub

The JuPnP 2.6.0 release is done. Kai submitted the PR to update OH to that now. So hopefully, in the next few snapshots, this will all be said and done.

Thanks @morph166955 for your help and of course thanks to @Kai
Hopefully after two and a half year this issue is officially solved :smiling_face_with_three_hearts:

Within the next weeks I will use the new version and give feedback!

Thanks, again!

Snapshot 2414 includes the update.

Full breakdown of the new configuration items for anyone who needs it.

1 Like

In the meantime I updated to openhab 3.1.0 stable .
First I still had issues after a week because I used this config. Not sonos binding was my problem, the samsung binding got somehow frozen.
I changed the setup to the one morph166955 suggested in the post above and since then everything was fine.

My setup for raspi 3 B:
org.jupnp:threadPoolSize=20
org.jupnp:asyncThreadPoolSize=20
org.jupnp:retryAfterSeconds=30
org.jupnp:retryIterations=5
org.jupnp:timeoutSeconds=10

Just to be clear and avoid confusion, the only non-default value there is retryAfterSeconds. The rest are all system defaults.