shinyproxy: 503 Response being returned from Shinyproxy to Loadbalancer
I have a shinyproxy sat behind a google load balancer and when accessing one of the configured applications the proxy will return a 503 response when some assets provided by the application are accessed.
The assets that fail aren’t always the same though. Sometimes the logo on the applications start page doesn’t load then it will when the page is reloaded and the browser cache ignored. The same can be said for CSS documents too.
The Loadbalancer is provided via the Google compute service and is configured to handle the SSL stuff for the proxy. Everything behind the loadbalancer for the moment is just HTTP
My shinyproxy config is:
shiny:
proxy:
title: Test-shiny
logo-url: https://assets.local/logo.png
landing-page: /
heartbeat-rate: 1000
heartbeat-timeout: 1000000
container-wait-time: 1200000
hide-navbar: true
port: 8080
authentication: none
docker:
url: http://localhost:2375
port-range-start: 20000
apps:
- name: test-app
display-name: test-application
description: test application
docker-image: test-r-app:latest
logging:
file:
shinyproxy.log
level:
root: DEBUG
I have packet captures from inside the docker network that show all is well and the request is served properly. The packet captures i have from shinyproxy however show its returning a 503 to the loadbalancer IP’s
Network diagram of sorts:
{World} --> [Google LB] --> [shiny proxy instance (Docker service) ]
If the LB is turned off shiny seems to be fine, however i kind of need it for what i want to do
Does there need to be extra config set for shiny to make it play nice with a loadbalancer ?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 21 (6 by maintainers)
Commits related to this issue
- Set proxy client's max queue size The default value for LoadBalancingProxyClient's max queue length is 0. As soon as the target is busy serving a request we will return a 503 rather that waiting for ... — committed to johan13/containerproxy by deleted user 4 years ago
- Fix #22363: set max queue size to 100 See https://github.com/openanalytics/containerproxy/pull/39 See https://github.com/openanalytics/shinyproxy/issues/65 Tested using siege performance test tool u... — committed to openanalytics/containerproxy by LEDfan 4 years ago
I can report that this is still an issue with the latest shiny.
Any find an issue on the shiny repo detailing the http/2 problem?
This should be fixed in ShinyProxy 2.4.0, therefore I’m closing this issue. @johan13 @k----n @nysthee (and others) don’t hesitate to re-open the issue (or open a new issue) if the problem persists.
Hi @nysthee,
I’ve got a similar setup, I’m disabling http2 on the ingress controller by linking it to a custom config map with the
use-http2: falseoption, and it works fine.@mcrmonkey It is the speed of the underlying Shiny technology that is problematic, I think, not ShinyProxy itself. Note that starting from version 1.3.0 of Shiny (see NEWS file)
So it may be worthwhile to use the latest version (now 1.3.1) and see whether the situation has improved.
Same here issue using jwilder/nginx-proxy infront of docker container(s) running Shiny Proxy. It’s also about 50% of the requests where we receive 503. (Only in Edge though)