fc4-framework
fc4-framework copied to clipboard
ClosedChannelException raised after computer went to sleep and woke up hours later
As a User
Given that I have started an fc4 session watching for changes with a command like fc4 -fsrw *.yaml
And I have changed a yaml file and successfully render a png
When my computer went to sleep for a few hours and was then awakened
And I make another change to a yaml file
Then I should not have this exception raised (I split the line for readability):
20:09 container_current.yaml modified; reading+parsing+validating...✅ formatting...✅ snapping...✅
rendering...🚨Error processing [/Users/miketheman/workspace/miketheman/docs/container_current.yaml]:
java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.nio.channels.ClosedChannelException
I'm guessing that fc4 opens a Chrome connection the first time it starts, but something in Chrome might time it out when asleep? I haven't done much searching yet.
$ brew info fc4 | grep Cellar
/usr/local/Cellar/fc4/2019.10.04-117ecb9 (5 files, 21.2MB) *
$ java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
macOS 10.14.6 (18G1012) Chrome Version 78.0.3904.108 (Official Build) (64-bit)
Thanks for the excellent bug report! I’ve seen this a few times myself, but hadn’t gotten around to logging it. And yeah, after FC4 launches the browser, it then connects to it via WebSockets to control it via the Chrome Devtools protocol. I suppose one side or the other closes the connection after some idle period. And it’d definitely be better for FC4 to automatically reconnnect or something like that.
Thanks!
Update: in light of #268, the priority of #5 is now much higher. That will involve implementing a new, in-process, offline renderer, which should resolve this class of problem.