Closed ruslandoga closed 1 year ago
DB connection is mostly about the pool and it leaves the lazy connections, auto reconnects, etc all up to users, exactly because semantics between adapters can vary widely. :)
also good call on using mint!
@josevalim thank you for the info! Somehow I had an idea that db_connection
is best used when it has full control.
👋
When using Clickhousex implementation of DBConnection behaviour, logs and sentry get filled with "disconnected" errors.
Clickhousex uses HTTP to connect and send requests to the database. It used to be
:hackney
, now it's:mint
. The error seems to appear with both. Taking:mint
as example, I assume the connection gets closed while being checked in, and when the query (POST request) is sent to the database,:mint
returns a transport error "closed" and dbconnection restarts the process with that disconnect reason.I'm looking into possible workarounds and one of them is checking that the connection is open in
checkin
andcheckout
callbacks and if not -- trying to reconnect once. If newconnect
is successful, new state is returned with the new connection, if not,{:disconnect, state, reason}
is returned which leads to dbconnection to take over the reconnection and log the disconnect error. This workaround doesn't look clean as reconnect logic is better left out to dbconnection to deal with entirely.Maybe there is some other way to avoid this error being logged in a case when the first reconnection attempt is successful?