How to properly handle worker_threads termination, when there are some node instances? (Like docker-swarm or Kubernetes cluster)

Question

I'm creating worker_threads in node and I'm collecting them to custom WorkerPool. All workers are unique, because they have unique worker.threadId. My app have ability to terminate specific worker -- I have terminateById() method in WorkerPool.

So if you have one node.js instance -- everything is all right. But if you're trying to use docker-swarm or Kubernetes -- you will have n amount of different WorkerPool instances. So, for example, you have created some workers in one node instance and now you're trying to terminate one -- it means you have some request with threadId(or other unique data to identify worker). For example your load balancer have chosen to use another node instance for this request, in this instance you have no workers.

At first I thought, that I can change unique index for worker to something like userId+ThreadId and then store it in redis for example. But then I haven't found any info about something like Worker.findByThreadID(). Then what can I do in situation, when you have multiple node instances?

UPDATE: I have found some info about sticky sessions in load balancers. That means, that using cookies we can stick specific user to specific node instance, but this in my case this stickiness has to be active until worker is terminated. It can last for days

Answer 1

So, I have two answers.

1. You can use sticky session in your load balancer in order to route specific user request to specific node.js instance.
2. You can store workers statuses + node.js instance id in redis or any db etc. When you're getting stopWorker request -- you're getting info from redis about node instance where the worker has been initialised. Then you're using any message broker to notify all node instances, message consists of nodeInstanceId and workerID, every instance checks if it's itself and if so, then go to current WorkerPool and terminate worker by id