vcs-js server stops responding after timeout?

[James-Crean]

When running vcdat it seems like the vcs-js server will stop listening to the socket if it doesnt get a connection after some set amount of time.

Steps to reproduce:

1. Run vcdat as normal
2. Do not attempt to visit the site for at least 5 mins. (This includes typing the url into the address bar as some browsers try and visit the page before you hit enter)
3. After 5-10 mins attempt to load the localhost:5000 page. vCDAT should be served by flask, but should warn that vcs-js is not defined. (This error appears when the connection to vcs-js is closed.)

[scottwittenburg]

This is expected, and is controlled by an optional --timeout argument you can provide to the server script (scripts/vcs-server). The default value is 300, which is measured in seconds and thus, results in a 5 minute timeout. The timeout is used to stop the server process in two cases:

1. No initial connection is made to the server within the timeout period.
2. A connection is made, but the tab is closed or the user navigates away from the application using the back button or similar. Then, if the user doesn't return within the timeout, the server is stopped.

[James-Crean]

Is there an option to turn this behavior off? (Like passing 0 for the timeout or something similar?)

[doutriaux1]

@James-Crean turning it off completely seems like a bad idea especially in case #2 from comment above. Maybe set it to something really big, like 12hours.

[James-Crean]

As a desktop app, I certainly see the value in having a timeout. I'm mostly thinking for when we eventually do server deployments, and we actually want it to run forever.

[doutriaux1]

@James-Crean are we going to have one vcs-js per user? If so, make the timeout match the user session timeout.

[scottwittenburg]

@James-Crean I don't understand why you would ever want one of these user visualization processes to run forever. They should be launched on-demand and on a per-user basis, then be shut down when the user ends their session. But maybe I don't understand what you're imagining for these eventual server deployments.

[James-Crean]

@scottwittenburg I like the idea, but how will it work exactly? Flask could certainly do it, but last I heard, we were trying to get rid of it. I thought during one of our meetings someone mentioned vcs-js serving the html and js files as well as handling authentication, which I thought implied that some sort of server would be running indefinitely, and that it would spawn off instances of the vcs-server as needed.

[scottwittenburg]

IIRC, we had talked about using our wslink launcher in the short term, until and unless we ever need a custom solution based on the scheduling system of whatever HPC system this thing will eventually run on.

The role of that launcher would be stay running all the time and start the visualization processes, on-demand and one per user. It can also serve static content at the same time, though an Apache frontend would probably be better for that.

I think I shared some documentation regarding this stuff at one time, but as a reminder, our paraviewweb github.io is the place to find that kind of thing:

http://kitware.github.io/paraviewweb/docs

Sections with relevant documentation include the ones titled "Server", "Launchers", and "Deployment". You may want to read through some of those, and then it might make sense to set aside some time (maybe even while I'm visiting at the end of next month) to sit down and draw some pictures of how your deployment might look.

You're right that we have discussed getting rid of flask, though we haven't taken any steps toward that yet. The last time I looked at the vcdat repo, it seemed like it wouldn't be too difficult to replace all those endpoints with rpc methods within vcs-js. We probably want to do that as a part of the "one-process-per-user deployment" effort.