Clarification on single-replica app persistence with redis

ShinyProxy
1

Quoting the docs:

Note that it is possible to use the high availability mode with a single replica. This allows you to restart ShinyProxy without having the apps of users stopped, although there is still some downtime when ShinyProxy restarts.

With the following (working) configuration in place

spring:
  session:
    store-type: redis
  data:
    redis:
      host: 172.17.0.1
      username: default
      password: {{ valkey_password }}
      database: 10    
proxy:
  store-mode: redis
  stop-proxies-on-shutdown: false

when restarting ShinyProxy (running in docker), apps of users are stopped and are not persisted across restarts.

While this matches with the statement “although there is still some downtime when ShinyProxy restarts”, I am confused about the other part which states “This allows you to restart ShinyProxy without having the apps of users stopped”.

Can somebody shine light on what is actually true now? (and whatever the outcome is, the two statements seem to annul each other in their meanings, so in which scenario can both be true at the same time?

2

Hi, the above configuration should store everything in Redis. Can you provide your full config file? Can you also provide the logs, it should indicate whether Redis is being used for persistence.

although there is still some downtime when ShinyProxy restarts

This sentence means that during the short period that ShinyProxy is restarting, the platform is down. But as soon as it’s fully started again, the running apps should still be there.

3

Redis is in use and picked up.

This sentence means that during the short period that ShinyProxy is restarting, the platform is down. But as soon as it’s fully started again, the running apps should still be there.

OK, thanks, I think I understand now. This means that the app state is preserved, i.e. when the user reconnected to the app, after ShinyProxy itself is back up, the app will be in the same state as before the disconnect.

Yet it does not mean that there won’t be a disconnect. A restart usually takes ~ 10s roughly, in which case the user experiences a disconnect. In my setup, with websocket auto-reconnect, this will result in a dynamic reconnect timer being shown.

What confused me initially was the claim of “high availability” is possible with a single replica. Reading this, I expect no disconnect at all for running apps (at least). Users connecting in a fresh session surely won’t have a connection.
I think using the term “high availability” here even though both running and new session experience a disconnect of ~ 10s is a false promise.