12/22/2023 0 Comments Work queueDo you need schedulability? (then use a job queue).If you do, and you're on the fence about which solution to choose given your use case, it may make sense to use queues if you already have them setup.Do you already have queue infrastructure setup, a library selected, pattern for calling it, etc.?.That's logic you would have to implement yourself in the "main" thread. Obviously you can mitigate this by having a "global" error even listener and handle the exception there,īut even in case of a single worker thread failure another worker thread would have to be spun up and would not automatically recover. If that happens in a job consumer/processor, you still have all the others runningĪssuming you have more than one consumer. Instead, if you have a CPU-intensive task that only has a single step - where failure may mean less than if you have a multistep process, in which case you'd likely have to rollback certain things at certain steps -Īnd you can afford to let it fail, a worker thread might be the right choice for your use case.Īnother important thing to note - an uncaught exception will kill the whole process, taking all threads including the "main" Node thread down with it. Tracking of which ones failed, initiating retries, etc. And since the "main" Node thread is the orchestrator of the worker threads, it would be something you'd have to implement at that level, including There might be some libraries out there that do this that I'm not aware of, but the general idea is that retry-ability In contrast to a job queue (via the library you're likely using), you need to implement retry logic, scheduling, and priority levels for the worker threads yourself. To use queue terminology, in this case worker threads are generally the "consumers", and the "main" NodeJS thread is the "producer". I say "semi-isolated" because they still run as part of the same process as the "main" NodeJS thread. This is an important distinction, because having multiple event loops is a big part of what allows worker threads to work as semi-isolated. Of course, you would need a lot of other code and features to implement that pattern - simply "dropping in" worker threadsĭoesn't automatically mean you have a job queue - but it can be done.Įach worker thread has its own V8 instance and event loop, compared to single-threaded NodeJS where there is one event loop that all code uses. This primitive is a building block used to constructu a larger abstraction, and you could even use worker threads to implement the job queue pattern. "Worker threads" are more of a primitive as opposed to an architectural or design pattern. The service that produces/schedules/creates the jobs is the producer,Īnd the service(s) that do the work are consumers. With a queue, the jobs are usually run in a separate component/service from the application producing the jobs,Īnd can run in parallel with it. If the main process dies, it will take down all threads with it. Instead, if you handle all of that in application memory then it will be ephemeral, and less able to recover upon failure. Job queues generally provide features like scheduling, coordinating, and retrying jobs, which helps with scalability as well as "fault-tolerance". It's not a part of the NodeJS API, but is a pattern you implement (or a third party library implements for you), So what are the differences and when would you use which one? Job queueĬompared to worker threads, a "job queue" (or "task queue") is more of an architectural design pattern. With architecture choices I've found that once you decide on it, it can be more difficult to change compared to changes at the "code-level", so best to pick the right solution for your problem/use case off the bat. Getting a better grasp on these will help you know when to use which solution, and help you implement your designs faster and in a more robust way. With both you are "outsourcing" work to be executed elsewhere besides the event loop. Two of these patterns/methods that might be confusing as to when you would use which one due to perceived similarities are job/task queues and worker threads.īoth are options if you want to handle computationally heavy work and not block the event loop. Whether you're dealing with scaling up or computationally-heavy tasks, certain patterns/solutions will be the right choice over others. Queues, promises, worker threads, child processes, the cluster module, scaling horizontally with multiple containers, etc. There are several different architectural patterns and solutions for handling asynchronous code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |