I'd like to a specific example from a real app where using a separate queue isn't just as well.
On Tuesday, February 10, 2015 at 12:42:17 PM UTC-8, John Negron wrote: > > 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.
