sandstorm

sandstorm copied to clipboard

This is a thing I noticed which has driven me crazy, and I believe happens regardless of if I'm using a Linux or a Windows box for vagrant-spk: I do not thing grains are held open properly when active on the screen, and they have a habit of not working again when I try to relaunch a dev grain again later.

The Sandstorm log contains various entries of:

Unhandled exception in Promise:  [Error: remote exception: Peer disconnected.] {
  cppFile: '(remote)',
  line: 0,
  kjType: 'disconnected'
}
Unhandled exception in Promise:  [Error: remote exception: grain is not running] {
  cppFile: '(remote)',
  line: 0,
  kjType: 'disconnected'
}

In one case, I was navigating with enter-grain, and got booted out. When I tried to run enter-grain again... I got "No Sandstorm supervisor processes found."

I thought it might be me or bad app code on my part, but it's happened to me on multiple apps written in multiple stacks.

Discussed on IRC, but: it seems like there are two separate issues:

1. Sandstorm does not keep apps open just because the UI is open; actual traffic to the grain is required.
2. There is some problem with restarting grains in dev mode.

(1) is definitely not vagrant-spk specific, and I would be very surprised if (2) was; perhaps we should move this to Sandstorm's tracker?

Done.

Re. 1. As noted on IRC, my tendency to use PHP with no real client side code probably exacerbates the issue for me, because there's little traffic while the app is open/in use, and even while I am entering form data. I was also surprised/annoyed that the grain terminated while I was using enter-grain to navigate the sandbox. I feel like dev mode might benefit from an extended timeout period or something.

Re: 2. From my observation, killed or closed dev mode grains do not restart, and I often end up using a new grain for each test when in dev mode. The "restart grain" button immediately causes the issue for me as well.

https://github.com/ocdtrekkie/simple-helpdesk-php is the package I am playing with at present. Which as noted, also doesn't allow INSERTs into the database... though SELECTs work fine, and I don't know what's up there yet.

wrt. keeping the grain alive, I think we should just change the behavior so that keeping the grain open is enough; I think that was the original intent anyway.

I'll try to find some time see if I can reproduce the restart problem soonish.

This might not be worth bothering with, but I'm imagining some developer wanting their app to be routinely shut down even while a “session” is open, on the principle of the chaos monkey / “if your backups aren't regularly tested they're broken”. Or, perhaps less plausibly, saving resources under the combination of “expensive to keep running” and “user might keep the tab open without interacting with it”.

Thus, it might make sense for the app to be able to declare the conditions under which it should be kept running, in its manifest. This would also help nail down the API between Sandstorm and the app — if there's ever motive to change the policy again in the future, explicit metadata about the app's expectations helps not break old apps.

@kpreid I think we want dev mode to definitely still kill grains like during production, but it may be a bit too aggressive when you are switching between Sandstorm and the code you're working on and the terminal. If we fix the grain shutdown behavior globally to not kill a grain if it's the active tab in the browser, it would cover my need here as well though.

My inclination is to make the switch without adding a bunch of knobs or complex logic, and if problems arise deal with them then.