Update shinyproxy when application.yml changes

I haven’t found in the docs a way to make shinyproxy update, i.e., re-read application.yml, without restarting shinyproxy. Did I miss anything?

The background to this question is that we are planning on running shinyproxy as a service and would want to add or update apps without killing currently active ones.

Thanks again for the great work and responsive community

6 Likes

Hi @msenn,

Good question. For updating apps it is not needed to restart ShinyProxy: if you update Docker images, Docker will run the latest ones. When updating app configurations or adding apps, it is currently required indeed to restart ShinyProxy.

If the behaviour you are after is supported by Spring Boot, we can support it for ShinyProxy too.

With the current behaviour, note that an admin user can see the live usage of ShinyProxy in the admin view, so you can know you are not bothering users (or which users exactly you are potentially bothering) when doing a restart.

Best,
Tobias

Hi Tobias,

Thanks for your answer. It’s good to know updates work without restart. Also, your hint with admin view should make the occasional restart rather painless.

Still, I’d love to see the capability of updating while running – if Spring Boot allows, that is. Unfortunately, I can’t help with the tech :disappointed:

Thanks,
M

1 Like

I am with @msenn. It would be lovely to not have to reboot the server any time there is a change.

PS: thank you for this great tech!

I am also facing a few issues with this, but we are a few versions behind, is it fixed in more recent versions?

I found these similar threads:
https://discourse.openanalytics.eu/t/adding-new-applications-without-restarting-shinyproxy/200
https://discourse.openanalytics.eu/t/add-apps-without-restarting-shinyproxy/309

I have configured automated pipelines to build containers from user git repositories and then publish the resulting containers using ShinyProxy. When a user creates a new repository (dashboard), or changes metadata (eg. title/description), the CI/CD process builds the container and it gets pushed to the container registry and automatically updates the application.yml with the dashboard metadata. Unfortunately, the pipeline then needs to restart the shinyproxy service for the new dashboard/metadata to be made available.

Initially this wasn’t really an issue, but as more developers start pushing dashboards, the restarts of the shinyproxy service for newly created dashboards/metadata changes is impacting the end users/consumers more regularly.

With the ongoing restarts i’ve unfortunately had to move promotion of new dashboards to production out of the pipeline and schedule restarts after hours.

If there was a SIGHUP equivalent that re-reads configuration, it would be perfect.

I notice there was some more recent discussion on github here:

With regard to reloading the configuration, would it be possible to split the configuration information out of application.yml, so that there is a configuration file that only includes dashboard information, and then have the service re-reads this file on load of the landing page?

ie.
config.yml <-- loaded when application starts, and includes application configuration
application.yml <-- loaded dynamically when users hit the landing page and contains dashboard configuration

Thanks to everyone working on this, it’s a great product we get lots of value from.

1 Like

hi,

any news about this functionnality ? I will be a really nice feature.

Regards

1 Like

The idea described by @pixdrift would be really nice. Any hope for it to become a feature?

I was expecting this to be possible given the website description, but now I understand “update” refers to updating current applications.

  • If you have multiple ShinyProxy containers and want to put a new configuration online, you can perform a ‘rolling update’ without causing any downtime for your users.

We could copy the application.yml, change the port, create/update the shinyproxy image (as the Dockerfile copies the yml), create a new service publishing the new port (e.g. 8081:8080), and update a reverse proxy? Still there’s downtime as at some point the old service must be shut down.