sideofbacon

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

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.

Yay!

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.

Thanks! That's really helpful context.

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

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.

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.

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.