Distributed action-listener // multi-threading
0

3 posts in this topic

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? 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0