solid_queue
solid_queue copied to clipboard
basecamp
Are there plans to support Action Cable with Solid Queue?
Solid Queue's internal queueing mechanism makes it a good fit for Active Job, and can serve as a replacement for Redis-backed job queues.
Are there also plans to support Action Cable as an Adapter?
Postgres already serves as a relational database-backed Cable Adapter (through the ActionCable::SubscriptionAdapter::Postgres class) as an alternative to Redis. Since Solid Queue aims to bring Postgres-like queue mechanisms to other SQL databases like sqlite and mysql, Action Cable could stand to benefit from that work.
What would it take to re-purpose what's already built to serve both Active Job and Action Cable?
Ohhh, good question! That's not currently in my plans because the Action Cable adapter relies on very specific PostgreSQL's features, namely LISTEN / NOTIFY. I'm not sure Solid Queue tries to bring Postgres-like queue mechanism to MySQL, but rather, it tries to implement queue mechanisms using what MySQL already has 🤔 That is, instead of relying on Postgres's queue-like features, it ignores these and relies on other common features (and plain, boring indexes to optimise certain queries) to serve as an Active Job backend. Did I understand your question correctly?
Did I understand your question correctly?
I think so, yes.
I'm not sure Solid Queue tries to bring Postgres-like queue mechanism to MySQL, but rather, it tries to implement queue mechanisms using what MySQL already has
My assumption was off base, so thank you for helping to clarify my understanding of those underlying mechanisms. I'd understood Solid Queue to draw inspiration from good_job. The good_job README explicitly mentions:
Backed by Postgres. Relies upon Postgres integrity, session-level Advisory Locks to provide run-once safety and stay within the limits of schema.rb, and LISTEN/NOTIFY to reduce queuing latency.
I'd misunderstood Solid Queue's positioning, and made the mental leap that since Good Job relied on LISTEN, NOTIFY, and UNLISTEN to function, then Solid Queue must be re-implementing those features in a SQL-agnostic way.
If that isn't the case, I wonder what it'd take to provide an out-of-the-box SQL adapter for Action Cable. With Solid Cache serving as an SQL cache store and Solid Queue serving as an SQL job queue, Action Cable is the last remaining built-in framework that pulls in a Redis dependency for production-like environments.
@seanpdoyle-intercom Related thread - https://github.com/rails/rails/issues/50480
@seanpdoyle-intercom fwiw I made https://github.com/npezza93/solid_cable which adds an action cable adapter for mysql and sqlite.
@rosa did you mean to close with reason not-planned? While I was excited for a minute, I don't see commits showing a change to what you'd said above: this is "not currently in my plans" for solid_queue.
Hey @ansonhoyt, right! Not quite as not planned, but it's more in the line that Solid Queue is not related to Action Cable in any way, so this doesn't quite fit here.
Have you checked out Solid Cable? https://github.com/rails/rails/issues/50480 I think that should be the right approach for this.
It works with pg but Postgres does have its own cable adapter that doesn't rely on polling. The only reason to use solid cable over the dedicated pg adapter is if you are sending more than the 7kb limit of Postgres