Hi friends,
I created a shiny application and dockerized it using the below dockerfile
FROM r-base:3.5.1
RUN apt-get update && apt-get install -y
sudo
gdebi-core
pandoc
pandoc-citeproc
libcurl4-gnutls-dev
libcairo2-dev/unstable
libxt-dev
libssl-dev
RUN wget --no-verbose …
gdebi -n ss-latest.deb &&
rm -f version.txt ss-latest.deb
RUN R -e “install.packages(c(‘shiny’,‘shinydashboard’, ‘DT’, ‘plotly’), repos=’,…’)”
COPY /app /srv/trialconnect-dashboard
COPY Rprofile.site /usr/lib/R/etc/
EXPOSE 3838
CMD [“R”, “-e”,“shiny::runApp(’/srv/trialconnect-dashboard’,port=3838,host=‘0.0.0.0’)”]
And my shinyproxy applicaiton.yml is as below for the app section
id: trialconnect-dashboard
display-name: Trinetx Trial Connect
description: Trial Connect Studies with Provider Information
container-cmd: [“R”, “-e”, “shiny::runApp(’/srv/trialconnect-dashboard’)”]
container-image: trialconnect-dashboard
And I am getting this error, can you please help me with this issue…
2019-03-25 23:44:39.202 WARN 9621 — [ XNIO-2 task-4] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (9/10): http://f09f00a3c33b:3838
2019-03-25 23:44:41.204 WARN 9621 — [ XNIO-2 task-4] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (10/10): http://f09f00a3c33b:3838
2019-03-25 23:44:43.773 ERROR 9621 — [ XNIO-2 task-4] io.undertow.request : UT005023: Exception handling request to /app/trialconnect-dashboard
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is eu.openanalytics.containerproxy.ContainerProxyException: Container did not respond in time
at
Hi @nandan_83,
As described at https://www.shinyproxy.io/troubleshooting/ there could be multiple reasons for that error.
Can you please try to run your application from the docker container independently of shinyproxyand see if it helps pinpoint the error?
sudo docker run -p 3838:3838 trialconnect-dashboard
Hi @mnazarov,
I tried running the run command you send and it was working successfully and I was able to browse through the website, but when I try it using shinyproxy, I keep getting the same error.
Also one more thing, I noticed is removed the internal-networking : true from my application.yml.
It started pinging the http://localhost:20000. Is this the correct behavior, but with same error
2019-03-26 15:39:33.481 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (2/10): http://localhost:20000
2019-03-26 15:39:35.494 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (3/10): http://localhost:20000
2019-03-26 15:39:37.503 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (4/10): http://localhost:20000
2019-03-26 15:39:39.512 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (5/10): http://localhost:20000
2019-03-26 15:39:41.518 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (6/10): http://localhost:20000
2019-03-26 15:39:43.523 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (7/10): http://localhost:20000
2019-03-26 15:39:45.532 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (8/10): http://localhost:20000
2019-03-26 15:39:47.539 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (9/10): http://localhost:20000
2019-03-26 15:39:49.551 WARN 2490 — [ XNIO-2 task-8] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again (10/10): http://localhost:20000
2019-03-26 15:39:52.395 ERROR 2490 — [ XNIO-2 task-8] io.undertow.request : UT005023: Exception handling request to /app/trialconnect-dashboard
Thank you
Nandan
Hi Nandan,
I have another idea: in your application.yml I see:
I don’t what you have in the Rprofile.site, but you need to specify the port and the host. You actually have it in the Dockerfile’s CMD, so you can either omit the container-cmd line from the configuration file (then the default CMD from Dockerfile is used), or adapt it.
Hi,
I removed the contained-cmd from the yml file. I am getting this error below.
This is what I have in RProfile.site file
local({
options(shiny.port = 3838, shiny.host = “0.0.0.0”)
})
And yml contains
- id: trialconnect-dashboard
display-name: Trinetx Trial Connect
description: Trial Connect Studies with Provider Information
container-image: trialconnect
access-groups:
ERROR
2019-03-27 09:47:43.354 WARN 16503 — [ XNIO-2 task-15] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(6/10): http://47d3696910a7:3838
2019-03-27 09:47:45.356 WARN 16503 — [ XNIO-2 task-15] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(7/10): http://47d3696910a7:3838
2019-03-27 09:47:47.358 WARN 16503 — [ XNIO-2 task-15] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(8/10): http://47d3696910a7:3838
2019-03-27 09:47:49.362 WARN 16503 — [ XNIO-2 task-15] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(9/10): http://47d3696910a7:3838
2019-03-27 09:47:51.364 WARN 16503 — [ XNIO-2 task-15] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(10/10): http://47d3696910a7:3838
2019-03-27 09:47:53.874 ERROR 16503 — [ XNIO-2 task-15] io.undertow.request : UT005023: Exception handling request
to /app/trialconnect-dashboard
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is eu.openanalytics.containerproxy.ContainerProxyException: Container did not respond in time
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:986) ~[spring-webmvc-5.0.4.RELEASE.jar!/:5.0.4.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:881) ~[spring-webmvc-5.0.4.RELEASE.jar!/:5.0.4.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[javax.servlet-api-3.1.0.jar!/:3.1.0]
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:855) ~[spring-webmvc-5.0.4.RELEASE.jar!/:5.0.4.RELEASE]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[javax.servlet-api-3.1.0.jar!/:3.1.0]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) ~[undertow-servlet-1.4.22.Final.jar!/:1.4.22.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) ~[undertow-servlet-1.4.22.Final.jar!/:1.4.22.Final]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:320) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:119) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334) ~[spring-security-web-5.0.3.RELEASE.jar!/:5.0.3.RELEASE]
OK, then the container-cmd doesn’t matter, i.e. with the previous one it should also work.
Another possible cause is that it could be that the application takes longer than 20 seconds to load.
You can try to increase it with the option container-wait-time (see https://www.shinyproxy.io/configuration/#general).
Also, can you run any other app, e.g. example apps from openanalytics/shinyproxy-demo?
I already have container-wait-time: 20000, but it still only waits for 10 attempts.
proxy:
title: Open Analytics Shiny Proxy
logo-url: http://www.openanalytics.eu/sites/www.openanalytics.eu/themes/oa/logo.png
landing-page: /
heartbeat-rate: 10000
heartbeat-timeout: 60000
port: 9090
container-wait-time: 20000
authentication: ldap
I am not sure why it is not waiting for 20seconds, can I increase that or should I use something else.
I will give a try on the shinyproxydemo and see what happens…
Also should I deploy the app in root instead of /srv folder
Thank you for trying to help me
-Nandan
It is waiting for 20 seconds (10 attempts each 2 seconds), but what I suggested was to increase this 20000 to something larger, like 60000…
The folder shouldn’t matter.
I changed the time to 90000, and same issue, also I tried connecting using the shrine proxy demo and I am still getting the same error
2019-03-27 12:36:54.690 WARN 21031 — [ XNIO-2 task-1] e.o.shinyproxy.ShinyProxyTestStrategy : Container unresponsive, trying again
(45/45): http://da6047217bff:3838
2019-03-27 12:36:57.203 ERROR 21031 — [ XNIO-2 task-1] io.undertow.request : UT005023: Exception handling request
to /app/06_tabsets
Finally, I got it to work.
what I did was, I changed the host to be 127.0.0.1 where ever I used localhost in the application.yml
And also change the Rprofile.site host from 0.0.0.0 to actual server name(you can use the host IP address here too)
Thank you @mnazarov for all your help
2 Likes
Hello @nandan_83 !
I’m having the same problems here. Can you explain a little bit what you mean with:
“I changed the host to be 127.0.0.1 where ever I used localhost in the application.yml”
Best regards !
1 Like
Having the same problem and cannot find a solution. I am using the demo images and they run fine outside shinyproxy.
Already changed ports, increased timeout and changed the host from 0.0.0.0 to 127.0.0.1. However, after changing the host the application was not accessible anymore.
Interestingly I did work for a few days at first but suddenly this problem showed up.
Any ideas?
Figured it out - had to set the container-network to the proper value.
