[denonmarantz] Fix blocking initialization

[jlaur]

Resolves #16806

[lsiepel]

Thanks, very clean.

I would consider this for backporting, agree?

[jlaur]

I would consider this for backporting, agree?

Probably not, since it's not zero-risk, and I don't think it's critical - it's been like this for years. So I'd like to run it on my production system for some time to confirm there are no side-effects. I successfully tested two scenarios briefly:

1. Adding a Thing with non-existing IP address to reproduce timeouts/failing auto-configuration.
2. Initializing a working Thing for my receiver (i.e. skipping auto-configuration).

[jlaur]

@lsiepel - and now I realized I need to check what happens in case of dispose before the auto-configuration completes.

[lsiepel]

@lsiepel - and now I realized I need to check what happens in case of dispose before the auto-configuration completes.

I guess you want to catch the interruption exception and quit/return immediate and not start the second telnet connection

[jlaur]

@lsiepel - and now I realized I need to check what happens in case of dispose before the auto-configuration completes.

I guess you want to catch the interruption exception and quit/return immediate and not start the second telnet connection

InterruptedException is only thrown when the thread is interrupted. 😉 The issus is it was wild-running without a handle, and as a result "Handler DenonMarantzHandler tried updating the thing status although the handler was already disposed." and it kept trying to connect after it should have been disposed. I will need to check exactly why, because something else might also be going on.

I now did a change so the initialization job is scheduled and can be interrupted. It seems this also resolved the issue with endless reconnects. I will do a few more tests and checks tomorrow, so keeping as draft for now.

[jlaur]

I now did a change so the initialization job is scheduled and can be interrupted. It seems this also resolved the issue with endless reconnects. I will do a few more tests and checks tomorrow, so keeping as draft for now.

I had another look to figure out what was going on when creating a Thing with invalid IP address and quickly deleting the Thing again. It was more or less as expected: The initialization thread was not interrupted by dispose. Thus the initialization thread would call createConnection after dispose had called connector.dispose(). So indeed it is resolved with the change I made yesterday.