You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For various reasons we support several background job implementations in production — namely Que and Faktory.
We’re very interested in job-iteration, however an immediate issue we face (other than support being added #88 & #89, which I’m happy to do) was the fact that the gem attempts to discover and configure the interruption adapter up-front for a given worker — here. Unfortunately for us given our multiple queue implementations in play that share a codebase/monorepo, it means that we’d hit this branch, and be stuck.
I think supporting multiple background job implementations, while perhaps a little unusual, is a very useful use-case to support. Supporting multiple implementations allows for a lot more flexibility around migrating from system to system, or in cases where multiple background systems are desirable in order to place jobs on background systems with differing characteristics.
I would propose that instead of configuring the interruption adapter once during init for a given worker we just discover it around the execution of each iteration, I think this would be fairly achievable and am happy to take a look if this is a patch that would be of interest. 😃
The text was updated successfully, but these errors were encountered:
For various reasons we support several background job implementations in production — namely Que and Faktory.
We’re very interested in
job-iteration
, however an immediate issue we face (other than support being added #88 & #89, which I’m happy to do) was the fact that the gem attempts to discover and configure the interruption adapter up-front for a given worker — here. Unfortunately for us given our multiple queue implementations in play that share a codebase/monorepo, it means that we’d hit this branch, and be stuck.I think supporting multiple background job implementations, while perhaps a little unusual, is a very useful use-case to support. Supporting multiple implementations allows for a lot more flexibility around migrating from system to system, or in cases where multiple background systems are desirable in order to place jobs on background systems with differing characteristics.
I would propose that instead of configuring the interruption adapter once during init for a given worker we just discover it around the execution of each iteration, I think this would be fairly achievable and am happy to take a look if this is a patch that would be of interest. 😃
The text was updated successfully, but these errors were encountered: