UI grayed out for long running tasks unless interactivity took place

ShinyProxy
#1

Hi,

I’m currently doing some pretty time-consuming R analysis behind shinyproxy. I got this issue where the docker container is still active and running, however, the UI disconnected(grayed out) from the server. When I tried to reopen the app, it only loads the navbar and showing it’s busy. Shinyproxy log doesn’t have any information about what’s going on and the last line of the log is proxy activated for that app. The container log shows the R session is still running.

The long run function I’m using is Rsubread::align for sequence alignment. In my case, each align function takes about 10-15 minutes to return and it’s called in a for loop(usually around 10 iterations). If I interacted with the UI, then this issue will not happen.

Also, when I manually run the app by ‘docker run’, there is no issue.

One thing that I noticed is that the UI grayed out almost exactly after 10 mins(even if I changed the underlying dataset)

Below is the code block I’m using

observeEvent(input$runButton, {
for (…) { # around 10 iterations
long_running_task() # takes more than 10 minutes, involves writing files
}
})

Thanks a lot

Shiny apps time out/grey out after 10 minutes
#2

Hi Keqiang_Li,

Did you figure out a solution to your problem? I am having somewhat similar problem where after 5-10 minutes of user inactivity, my app does not grey out but none of my third part API calls work to completion and do not return any result.

I have to log out and log in again and only then it works.

Thanks!

#3

Did you try to configure the heart beat to a longer period of time in the shinyproxy configuration file?

#4

Yes, I have increased it to 30 mins.

Despite that, after 5-10 mins of user inactivity, even when the container is not killed, if I run anything or hit submit on the app, it just keeps on showing a loading symbol, never executes.

Only if I log out and sign in again and hit submit then it runs fine.

#5

I remember in the Shinyproxy javascript code, it basically send a request to the backend every a few minutes to check if the app is active. However, since R is single threaded, it might not respond to the request when it’s running other tasks. There should be a way to increase the heartbeat time frame. Also, you can check the new promise package for R, which runs long task in another thread and should be useful for this kind of Shiny web app.

#6

I think the heart beat signal is sent to the Java host and won’t be blocked. Should be other reasons like the browser may believe it’s a non responsive session and disconnects it after a while?

#7

I think you are right. Also, for the java backend to check if a R session is alive, it still requires the R session to be responsive.

1 Like
#8

Can you please tell me the code snippet we can use to check if R session is alive?

I used print(session$isClosed()) – and that gave me “False” even after inactivity period.

Also, can you please see my observations on this thread - ShinyProxy Container alive while process executing? and see if you can suggest anything?

Thanks!

#9

Regarding the heartbeat mechanism: indeed, this used to happen via separate AJAX requests, but changed in version 2.0.0.
Now, the heartbeat happens inside the websocket channel. Shinyproxy sends a ping frame to the browser, which under normal circumstances replies with a pong frame. These frames travel only between the browser and Shinyproxy, and never reach the Shiny app. Whereas all other websocket traffic is between the browser and the Shiny app, and Shinyproxy is just the ‘proxy in the middle’.

1 Like