Distributed action-listener // multi-threading

[Julian Martinz]

I am about to shift some specific actions from running locally on user-workstations to one or two central worker-clients. Some of these actions will run a little bit longer and won't be discoverable during processing. To keep it simple, maintainable and scalable I'd like to avoid setting up threading/multiprocessing mechanisms inside the action and do that on a higher level instead. Is there a canonical way to pull this off? If I understand it correctly the event.stop() method will only work if I register the listeners from one single process. So multiple-docker containers or multiple hosts won't work because this would lead to multiple actions with the same name showing up for users. Is that correct? Anything else to watch out for? 

[Lorenzo Angeli]

Hi Julian,
if you have long running jobs, the best option you have is to actually use multithreading from within the action ,
just be careful to use this solution as api are not thread safe, so the session will have to be created for each thread.overall though, my suggestion would be to use either a docker or a vm , where you can spawn a python process for each action you want to use, and potentially monitor them
through supervisor or a similar process , so if any dies it'll restart automatically.As you stated , running more of the single event won't work as it will register more than one.hope it helps.
L.

[Julian Martinz]

Hey Lorenzo,
Thats basically what I was planning to do (except for the threading part in the action .. but guess that's the only viable way). Thanks for the reply. 
- Julian