Closed lupestro closed 3 years ago
I no longer have vested interest in this change. Our need for named pipes ended when our deployments moved from in-house to Azure a year or more ago. With cloud deployment, we gained a lot more flexibility on how to deploy, and named pipes were a second-best choice even when I originally wrote this PR. Supporting FastBoot over named pipes can only introduce uncomfortable trade-offs for the far more important work you are doing in the strike team. However, rather than closing this outright now, I will leave the final decision up to you.
Gotcha, thanks @lupestro! I'm going to go ahead and close, though I'm not opposed to landing better support for this (we've moved to a monorepo over in ember-fastboot/ember-cli-fastboot) if someone else wanted to pick it up.
IISNode uses a named pipe to connect served node processes with the IIS web requests and responses. Node does not support connecting a named pipe to clusters of forked processes, which fastboot uses. Hence, fastboot, as it stands, cannot be used with IISNode or any other Windows layer using named pipes.
This PR uses the option { processCount:-1 } to place fastboot in a mode where, rather than forking a cluster of worker processes, a single worker runs within what would have been the parent process, . This does work with IISNode, and IISNode can be configured to spawn several instances of the single-process fastboot server to take advantage of multiple cores.