Client: add 1-5 minutes of delay after maintenance mode was enabled

[butonic]

otherwise an a large instance all sync clients will come back at once, hitting the system ... hard

[michaelstingl]

PR for maintenance mode detection: https://github.com/owncloud/client/pull/5755

[guruz]

@butonic btw, the web server should also be configured in a way so that it won't spawn too many PHP processes/threads and send 503 from web server layer.

@ckamm Is a random back-off easily implementable? I think maybe we don't even want this.

[ckamm]

@guruz I think this would be easy, we just need a random "coming back up" timer. I think it should apply to maintinance mode and bare 503.

[ckamm]

PR https://github.com/owncloud/client/pull/5874
It's currently not configurable -- does it need to be in a Theme?

[michaelstingl]

@ckamm Perhaps use an environment variable to disable this for debugging purpose. Otherwise debugging can become quite time consuming… (theming could be interesting too)

[guruz]

@michaelstingl Sorry, I think that's overkill and would pollute the code. Not worth it for this kind of feature.

[michaelstingl]

@guruz okay, then it's fine for me

[SamuAlfageme]

After quite a few tests, it seems pretty much behaving the way expected now - I'm with @guruz in this one:

the web server should also be configured in a way so that it won't spawn too many PHP processes/threads and send 503 from web server layer.

If switching off maintenance in the server was properly handled, there should be no need for this, which might affect smaller instances as collateral.

Also I'm worried, if the client could still be affected by a Byzantine 503 from the server (e.g. with some ext.sto. backends that do not behave so well like in https://github.com/owncloud/client/issues/5088) - being fooled into a 5'-wait when maintenance mode was not activated.

Closing here as behavior is the expected, we could keep the discussion on a core ticket.

[ckamm]

@SamuAlfageme A stay 503 won't make the client think maintenance mode is active. The server has to actively have maintenance: true in its status.php reply.

[SamuAlfageme]

@ckamm I expressed myself wrong:

being fooled into a 5'-wait when maintenance mode was not activated.

Should say "even when maintenance mode was not activated" which was the original reason to introduce the delay. And reading:

https://github.com/owncloud/client/blob/63741d95cebd9923c12023d8ac1d40205693499f/src/gui/accountstate.h#L153-L157

I was assuming both sources resulted on the application of the delay; is it wrong?

[ckamm]

@SamuAlfageme You're right, I forgot about that. Yes, a 503 reply to the auth check in connectionvalidator would also trigger the delay. A random 503 during sync would not though.