Open sgeos opened 6 years ago
As a temporary workaround, you could just restart the OTP application by doing:
Application.stop(:paddle)
Application.start(:paddle)
but I'm wondering if there are a better way of handling this, like adding a reconnect
function, try returning {:error, :timeout}
. If you have any ideas, let me know!
I just came across something strange: the default value of the :timeout
option from Erlang's eldap module (which this library is based upon) is :infinity
(see here).
So it might be that the timeout is not coming from the client / server connection.
Could you give more info about your issue ? (debug logs, etc.)
We enabled debug logging for our production build. I will post them in the future.
We changed the supervision strategy to :one_for_all
but it did not solve the problem. If anything is dying, I suspect it is restarted by the paddle application without reconnecting. A die on timeout or reconnect on timeout setting will probably solve our problem. Alternatively, perhaps :die
, :reconnect
and :restart
could be options for a timeout setting, where the current :restart
strategy is the default.
I'm not seeing anything in the log that is worth reporting. Is there a way to turn logging on for paddle that might be useful? For now we are restarting the whole containerized application every 30 minutes. It is a dirty fix, but it seems to be working.
I have found a way to get the :eldap
module to output some log using Logger
. I'm not sure if this will be very useful but we can still try.
The only way to crank the logging up for Paddle is to configure Logger
to output the :debug
level (which will now give us more info about what :eldap
is doing).
I'll make a minor release in a short time.
This is also addressed on pull #21
The problem may be on our end, but Paddle's LDAP connection appears to be timing out. The application works for a while, but the connection seems to go bad after a while. What is the best way to reestablish the connection when this happens?