Hacker News Reader

sideofbaconon Ruby Central's Attack on RubyGems [pdf]

Who? Everyone I recognize is continuing to contribute. https://github.com/rubygems/rubygems/graphs/contributors?fro...

sideofbaconon SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue

I'm the GoodJob author. Here's the class that is responsible for implementing Postgres's LISTEN/NOTIFY functionality in GoodJob:

https://github.com/bensheldon/good_job/blob/10e9d9b714a668dc...

That's heavily inspired by Rail's Action Cable (websockets) Adapter for Postgres, which is a bit simpler and easier to understand:

https://github.com/rails/rails/blob/be287ac0d5000e667510faba...

Briefly, it spins up a background thread with a dedicated database connection and makes a blocking Postgres LISTEN query until results are returned, and then it forwards the result to other subscribing objects.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

Yay!

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

That was mentioned in another thread. I have two thoughts about it:

- Going off of my own experience, I've never used PgBouncer and I've worked on some moderately sized applications (1s of millions of users). So I could say "not in scope for the target use-case".

- It would be possible to add an argument option to use a transaction-based Advisory Lock instead. I can imagine that would have downsides (long-running transactions, yikes).

I'm imagining that the lifecycle of GoodJob is that people starting new projects might choose it, and then the feature set would grow with their needs.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

Thanks! That's really helpful context.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

GoodJob author here. I'm curious why you're specifically looking for listen/notify? I'm trying to prioritize that in the backlog.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

GoodJob author here.

The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope

In practice any adapter should _just work_, but also all the other adapters pre-date ActiveJob (Rails 4.2) and Concurrent::Ruby (adopted in Rails 5.0 I think). The assumption is that building GoodJob on top of what already exists in Rails today, it can be performant (enough) and simple (easy to understand, maintain, keep compatible with new versions of Rails, etc). That's not a big claim, but maybe it's compelling.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

GoodJob author here. Excellent observation.

It should work if PgBouncer is using session-level pooling, but not transaction-level pooling. I made a ticket to document this: https://github.com/bensheldon/good_job/issues/52

I don't have much experience with PgBouncer. What's the scale/need when a team would use PgBouncer? That would help me prioritize supporting it better.

sideofbaconon GoodJob – a Postgres-based ActiveJob back end for Ruby on Rails

GoodJob author here. The reason is that I don't have any production experience with Sidekiq.

My target right now is someone, like myself, who would typically spin up a new project with delayed_job or que, and provide a better alternative with GoodJob.

Maybe in the future I'll do some more research on understanding why someone might switch from a Sidekiq/Redis to not-Redis.