search

ioBroker / dev-docs

Developer documentation
5 stars 4 forks source link

Best practice how to stop adapters #26

Open klein0r opened 2 years ago

klein0r commented 2 years ago

Explain

https://github.com/ioBroker/ioBroker.js-controller/blob/9ce695a3355a5f2e59532c070a55fdb76e0185b3/packages/adapter/src/lib/adapter/adapter.js#L245

https://github.com/ioBroker/ioBroker.js-controller/blob/9ce695a3355a5f2e59532c070a55fdb76e0185b3/packages/adapter/src/lib/adapter/adapter.js#L9223

Apollon77 commented 2 years ago

The stop link is "wrong" because this is the full internalmethod. exposed are:

https://github.com/ioBroker/ioBroker.js-controller/blob/9ce695a3355a5f2e59532c070a55fdb76e0185b3/packages/adapter/src/lib/adapter/adapter.js#L8932-L8943

In fact terminate bypasses the unload handling completely, so it needs to be used carefully and should not be used if the adapter support compact mode. So terminate is mostly used in schedule adapters (that are FOR NOW never run in compact mode) ... or adapter needs to make sure that all resources are free'd.

klein0r commented 2 years ago

So what's best practice now for scheduled adapters? I've had the issue, that the integration tests failed when the adapters quits "too early" (because .alive is false) -> https://github.com/ioBroker/testing/issues/474

Has

setTimeout(async () => adapter.stop(), 6000);

the same effect as setting common.stopTimeout: 6000 in io-package?

Apollon77 commented 2 years ago

Answer this this are:

  1. The cases where adapter added a "stop timeout" to their schedule adapter were jetzt because they did not cared about async nature and just fired all "setState" and such stuff without caring if it was really done. So they needed to add a waiting time tomake sure that in normal cases "all data are saved" :-) So ... NOT best practice! best practice is to use async/await and then you can "stop" directly afetr last command because you know it is done
  2. Schedule adapters that added a "kill timeout" (global after 30s end it) did that because they did not used timeouts for communication and so had issues with "instance hangs" ... also her e... best practice is clean development :-)
  3. common.stopTimeout in fact would only be the same in rare (unclean) cases. common.stopTimeout is used when an unload method is defined for the adapter AND the adaoter is not calling the unload callback within this timeframe - then the process is "hard stopped" after the given timeframe. But because unload logic should never not call callback it is unclean again (but yes calling stop and not calling callback would in fact have the same effect) :-)