It will totally depend on the app/buildpack. For example, the static file
buildpack and PHP buildpack just launch Nginx and then host the application
inside it. As soon as the web server is up it will accept connections so
they would work identically to IIS HWC with just a TCP healthcheck. For
others the framework would still likely start up and accept connections
before the app itself is ready, and again it would be very possible that the
app itself would crash the first time you actually hit it but the
healthcheck would still think the container is healthy.

Again, I'm not arguing that any of that is "good", just that is how the
platform is expected to work with a port check and it should work
consistently. I also agree that the (annoying) 30-60 second app warmup on
.NET makes this even uglier.

Assuming you do eventually make the port healthcheck for Windows work by
checking the port, it should be made to work. My understanding right now is
you do the following (high level):

* Spin up the "container" via the app lifecycle (create user, set quota,
create FW rules, etc.)
* Start up the HWC process
* Start running the healthcheck which hits the root of the app and checks
for 200-299 with a 1s timeout
* Add it to the router once the healthcheck passes

What if you did something like this:

* Spin up the container
* Start up the HWC process
* Hit the app once via HTTP as part of the startup to get the app going
* Put in a hard coded delay like 30 seconds to give the app time to start
(.NET penalty)
* Start the healthcheck after the delay
* Add it to the router when passing

Just brainstorming. :-)

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3695.html
Sent from the CF Dev mailing list archive at Nabble.com.