Concept: Optimize "unload handling" for adapters

[Apollon77]

Especially for the compact mode the adapterdevelopers needs to take care a lot to prevent that code is really not doing anything more when the unload callback is called. Especially cases where e.g. an external call needs longer then 500ms or a bigger loop needs that long there is code running in parallel to the unload call.

The question is what we can do to make it easier for the deveopers. Some ideas were collected already, but some of them would simply "hide" that there is more code running and make it invisible that there is still an issue:

• new adapter-setTimeouts should not be set when adapter was requested to be unloaded (or after unload callback call) - sure we can not help if someone uses official setTimeout method! -> we could do this already in controller 4 #1649
• adapter methods like sendTo should no longer be allowed after the adapter was requested to be unloaded (or after the unload callback?) - simply retun and do nothing would be best
• DB methods should not reject promises after unload callback was called

With all this it would be kind of hidden that maybe stuff still runs.

We should discuss what we want/should/could do better here to reduce the effort for adapter devs

[UncleSamSwiss]

About the "hidden" still running stuff: any call that gets "silently" cancelled could still create an error log message (even if the DB connection for this adapter instance is down, the js-controller is obviously still up and running and can post this log message)

[Apollon77]

We had this ... then the logfile exploded for users :-( so simply logging any case will not help ... we need to rate limit this somehow like "a logline every minute" or such ... and then it starts to get complex

[UncleSamSwiss]

We had this ... then the logfile exploded for users :-( so simply logging any case will not help ... we need to rate limit this somehow like "a logline every minute" or such ... and then it starts to get complex

I'm pretty certain if we don't allow any callbacks to be called, the log file shouldn't explode. That most certainly only happened because the adapter just wouldn't stop running.

I know there are (rare) situations where an adapter does some synchronous blocking code (honestly, I can only think about the synchronous childProcess methods), but in most cases, adapters will stop working if we don't trigger them anymore with callbacks (given timers are stopped).