Threading subscription notifications

[MaciejPMarciniak]

Hi, it's my first suggestion here, let me know if anything can be clarified or provided in a better format :)

Datachange_notification and event_notification usually involve operations like storing new data to the existing databases. These are usually expensive and/or time consuming, depending on the volume of the accessed data. In the provided examples, there is a note about handling such operations in separate threads, yet it is not clear at all how the new threads would affect the main thread loop in case of status changes and other server-related events, such that all threads exit gracefully.

Suggestion:

Assign threads for notifications by default, to allow for more complex activities within the notification methods.

[AndreasHeine]

mixing threads and asyncio is kind of a mess... what i did in the past is using asyncio.Queue within the SubHandler and process the queue in a workerprocesspool

[MaciejPMarciniak]

I agree, making them go together is challenging. I saw your example in opcua-sub-to-mqtt, it looks good but I cannot apply any version of it in my system, due to other components in play.

Currently I am just adding the datapoints through asyncio:
loop = asyncio.get_running_loop()
loop.call_soon_threadsafe(asyncio.ensure_future, self._insert_to_db(new_data))
It works most of the time, but sometimes I get timeouts.

Would there be another way to add it within the datachange_notification?