Plumber timeout

[JohnCoene]

Hi,

We have a plumber API deployed on RStudio Connect.
This API has an endpoint that can take some time to execute (> 1 hour).

The endpoint is pinged from the browser of another application with JavaScript using fetch.

What we notice is that if the user making the request closes the application (the browser window from which fecth was called) the plumber process exits after some time, it seems to timeout.

Which option will allow the plumber process to keep running?
The whole point of using an API here for us is precisely so we can run this in the background.

[meztez]

In RSConnect, there is a settings per deployment that lets RStudio connect shut down a process if it's not in use for some time. Content Settings - RStudio Connect: User Guide

Maybe related?

[edavidaja]

Does the API need to return a result to the browser? Given the calculation that's taking place takes at least an hour my first instinct would be to have the job send a message once it's complete.

[JohnCoene]

@meztez thank you, I know about these options it's the ones I refer to: I'm unclear which one stops the process.

@edavidaja it's taken into account, the response is not needed. The problem is really just that RSC kills the process.

[JohnCoene]

@edavidaja is it Read timeout that should be increased? It's difficult to understand the description (+ note typo: "A value of means...").

Maximum number of seconds allowed without data received from a client connection. Connections reaching this idle read threshold are closed. A value of means a lack of browser interaction will never cause the connection to close. This is useful when deploying dashboard applications which send regular updates but have no need for interactivity.

[sam.edwardes]

TL/DR - try increasing Connection Timeout. I can add some more detail on how these settings apply to APIs.

• Idle timeout per process: Minimum number of seconds a worker process will remain alive after it becomes idle - i.e. no active connections. For example:

  • The value is set to 5 seconds.
  • I make a request to /train_model. If the process is not yet running, it will spin up a new process and start running. The request takes 10 seconds to complete.
  • Immediately after the first request is complete, I make another request. Since the process is already running, it does not need to start up again. The request takes 10 seconds to complete.
  • After completing the second request, I wait 30 seconds and submit a third request. Since the API received no new requests within 5 seconds of the second request completing, the process has shut down. To serve the new request, a new process starts.

• Initial timeout: Maximum number of seconds to wait for a process to start. For example:

  • The value is set to 10 seconds.
  • The process takes 15 seconds to start because it loads a large data frame.
  • The API will not work because the 10-second limit is reached before the process has finished starting.

• Connection timeout: Maximum number of seconds allowed without data sent or received across a client connection. In the context of APIs, this will act as a time limit for how long a request can take after the process has started. For example:

  • The value is set to 5.
  • The API endpoint /train_model will take 10 seconds to train the data.
  • The API will return an error because it took too long.

• Read timeout: Does not apply to APIs, only relevant to Shiny for R and Shiny for Python content.