pggalaviz
Oban connection leak on (DBConnection.ConnectionError) ssl send: closed
Hi everyone,
I’m currently testing https://bit.io serverless postgres service, since its serverless connections are not expected to last long (as mentioned in their docs) and expect clients to use a connection pool to restart connections as needed.
So Ecto.Repo’s default pool seems to work fine, however when the connection is closed from the DBs server side:
Postgrex.Protocol (#PID<0.2701.0>) disconnected: ** (DBConnection.ConnectionError) ssl send: closed
Oban seems to create a new connection without killing the last connection process, increasing resources consumption.
In this example I have a Repo config with 10 for the default pool.
config :my_app, MyApp.Repo,
url: database_url,
pool_size: String.to_integer(System.get_env("POOL_SIZE") || "10"),
ssl: true,
ssl_opts: [
verify: :verify_peer,
cacertfile: CAStore.file_path(),
server_name_indication: to_charlist(database_host)
]
And as you can notice, there’s over 60 processes running now:
If I open any of those this is what I see:
Is there any Oban configuration I’m not aware of to fix this specific case that anyone would suggest?
Or is this an issue with Oban’s connections handling itself?
Thanks.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance













First 2 of 2 Posts
sorentwo
That’s from the Postgres notifier, i.e. pub/sub module. Those connections are meant to be long-lived, so it will reconnect when it encounters an error or a disconnection. If you’re running a single node or have a cluster, then I recommend using the PG Notifier instead.
pggalaviz
Thanks @sorentwo, that did the trick!
Still curious about why the process is never killed and the new connection just spawns a new one…