How can we test if RStudio Connect hosted application times out, then whether the database connections are also closed or not and the queries that may be running at the time of timeout are stopped?
This is a wonderful question! At present, the "cleanup" process that Connect fires on processes is not very flexible (i.e. we do not give processes much of a chance to clean up after themselves). I will add your feature request to have this be a bit more flexible.
That said, there are a few knobs that can be turned here. There are several hooks into a dying process. Connect does not allow some of these hooks to fire, but others will. You can try with these examples and use functional hooks to
dbDisconnect() or otherwise write code that cleans up after itself.
(NOTE: this one does not work: https://github.com/colearendt/plumber-entrypoint)
Finally, because the process that Connect is managing is the query "client," usually the client does not have any reliable way to "kill" queries that are already running on the database when the application is closed. As a result, running queries will usually persist after a process dies AFAIK.
Would you mind articulating a bit more about the reason for your question? Is it just curiosity? Have you run into particular issues?
There are applications hosted on R studio connect which times out in 20 minutes. We have observed there are related queries running in database for hours. So, in this scenario we would like to test what happens to database connection when the application times out? Does the database connection get closed or not? What will happen to the the queries which was running at the time of timeout? Those queries stops with the application or keeps running?
Can you please let me know how can I test this?
Also, if this feature can be added in upcoming releases that will be very helpful. Thanks
Sorry for the delayed reply here! We will definitely add your feature request to be added in upcoming releases.
I would definitely do a few things to test:
explore the different options I showed above. Though you do not have control over / hooks into the app timeout, you do have hooks into the session timeouts for users. This usually happens first, so you can have connection teardown happen when the session tears down.
Look at optimizing your queries. Interactive applications should not be executing queries that run for hours, period (IMHO).
What type of database are you using? I would research into that RDBMS and see if there are any client-side tools for controlling / killing queries that have run longer than anticipated. You may be able to set query timeout parameters, check query health, etc.
Again, there is an application example above that shows some teardown hooks that you have available within R / Shiny. As I said, standard behavior is for the queries to keep running because the client (R) dies and the server (database) keeps churning away.