Connection Timeout about paddle

[minijackson]

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!

[minijackson]

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.)

[sgeos]

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.

[sgeos]

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.

[minijackson]

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.

[shamanime]

This is also addressed on pull #21