[freeboxos] Bridge thing OFFLINE after OH restart

[lolodomo]

Almost all times I restart oipenHAB, the bridge thing will be OFFLINE / CONFIGURATION_ERROR / Exception while calling https://mafreebox.freebox.fr/api_version. If I restart the binding or disable/re-enalbe the brtidge thing, this is OK and the bridge is then ONLINE.

I just added a log and the problem is a timeout:

09:24:37.895 [WARN ] [ing.freeboxos.internal.api.ApiHandler] - Exception while calling https://mafreebox.freebox.fr/api_version
java.util.concurrent.TimeoutException: Total timeout 8000 ms elapsed
        at org.eclipse.jetty.client.HttpConnection$RequestTimeouts.onExpired(HttpConnection.java:334) ~[?:?]
        at org.eclipse.jetty.client.HttpConnection$RequestTimeouts.onExpired(HttpConnection.java:314) ~[?:?]
        at org.eclipse.jetty.io.CyclicTimeouts.onTimeoutExpired(CyclicTimeouts.java:110) ~[?:?]
        at org.eclipse.jetty.io.CyclicTimeouts.access$100(CyclicTimeouts.java:50) ~[?:?]
        at org.eclipse.jetty.io.CyclicTimeouts$Timeouts.onTimeoutExpired(CyclicTimeouts.java:196) ~[?:?]
        at org.eclipse.jetty.io.CyclicTimeout$Wakeup.run(CyclicTimeout.java:298) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [?:?]
        at java.util.concurrent.FutureTask.run(Unknown Source) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
        at java.lang.Thread.run(Unknown Source) [?:?]

I don't know why it happens only at OH startup. I will try with a bigger timeout.

[lolodomo]

The first OH restart with timeout set to 15s works. Will see after more restarts if this is "stable".

[lsiepel]

Another possible fix could be to adjust the delay of the scheduled task? Set it to 10 seconds or so?

https://github.com/openhab/openhab-addons/blob/9b9cdd579b376d9e2c583a7bb761f8c6dbaa3b8d/bundles/org.openhab.binding.freebox/src/main/java/org/openhab/binding/freebox/internal/handler/FreeboxHandler.java#L167

[lolodomo]

Why delaying more should change something ? You think it could be Jetty being too much used at this time ?

[lolodomo]

In the original binding, the timeout is set to 10s.

[lolodomo]

A first restart with timeout set to 10s (instead of default 8s) succeeded. Will keep this value and see if this is OK at each restart.

[lolodomo]

@lsiepel : your link concerns the other binding, freebox and not freeboxos.

In the new binding, it is even run without any delay: https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.freeboxos/src/main/java/org/openhab/binding/freeboxos/internal/handler/FreeboxOsHandler.java#L70

[lsiepel]

@lsiepel : your link concerns the other binding, freebox and not freeboxos.

In the new binding, it is even run without any delay: https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.freeboxos/src/main/java/org/openhab/binding/freeboxos/internal/handler/FreeboxOsHandler.java#L70

Oops, in my phone it is not so easy to navigate GitHub. my suggestion would be the same to delay the task. Answering the why question, delaying the scheduled task could give room to jetty to finish other tasks that are started at system startup. As this issue only occurs at system start.