Different backend workers/consumers have their own process management, configuration, etc. so relying on queue naming as a sole indicator of processing priority at an abstracted layer like ActiveJob means making some assumptions on the underlying backend worker configuration.
I was thinking this should be something adapter specific and left to the backend adapters to understand these per backend constraints; hence some delegation into the adapter from ActiveJob. On Tuesday, February 10, 2015 at 11:52:55 AM UTC-5, DHH wrote: > > That's still an open question. I'd like to treat each option we'd consider > passing on to a specific adapter as an invitation to discuss if we can > solve it in an adapter-agnostic way. > > What's the purpose of setting priority on the job rather than using > separate queues, in your mind? > > On Monday, February 9, 2015 at 8:36:38 AM UTC-8, John Negron wrote: >> >> ActiveJob is a great addition to Rails. Many supported backends like >> DelayedJob support other options than what is being passed into the enqueue >> adapter methods. It would be great if the "set" method could delegate >> options into the queue adapters. >> >> For example, DelayedJob has priority set at the job level and setting the >> priority could be done without named queues and other background workers. >> >> Are there any plans for that or would the group be open to a pull request >> for it? >> >> thanks >> John >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
