We’re looking at introducing RDS Proxy into our stack at Knock. We rely on Oban Pro (and love it!) however it looks like Oban Pro still relies on advisory locks internally. Advisory locsk force RDS Proxy to pin connections, which ideally we’d avoid. We wanted to check and see if there are other footguns here that we ought to be aware of? I read the Oban docs about PGBouncer, and we are using Phoenix PubSub instead of the Postgres notifier plugin already, which should avoid that issue.
I’m curious if it would make more sense to supply Oban with its own Repo that bypasses the proxy entirely, and have a more modest connection pool for Oban accordingly? Is that the preferred way to make this work, or is Oban known to work well with RDS Proxy?
Thanks for the kind words! We’re actually working on removing reliance on Advisory Locks for the upcoming Pro release. It will require a few configuration tweaks to enable, but it will be possible.
Notifications are the only other proxy/bouncer issue. You’re all set since you’re using the Phoenix/Redis notifier for pubsub instead.
Using a dedicated repo for Oban good idea in general, even if only for predictability. That’s one of the points made in our “Scaling Oban Applications” talk from ElixirConfEU, and will be part of a scaling guide soon.
There are other applications using the RDS Proxy and there aren’t any issues that I’m aware of.
We’re looking at introducing RDS Proxy into our stack at Knock. We rely on Oban Pro (and love it!) however it looks like Oban Pro still relies on advisory locks internally. Advisory locsk force RDS Proxy to pin connections, which ideally we’d avoid. We wanted to check and see if there are other footguns here that we ought to be aware of? I read the Oban docs about PGBouncer, and we are using Phoenix PubSub instead of the Postgres notifier plugin already, which should avoid that issue.
