I agree with your root argument that the port check doesn't really address
application health and it's easy to push a non-working app and have the
healthcheck still pass. My argument is that is exactly how the healthchecks
work for Linux-based apps and it seems clear that is the intent of the
"port" healthcheck. Any buildpack or Docker based app that I push on
cflinuxfs2 will pass as soon as the web server starts accepting connections
even if the actual app isn't working (yet, or at all).

I don't disagree that improvement can be made here, but I do strongly
believe that 1) the platform should be consistent across Linux and Windows
apps and what is described as a "port" check should just be checking the
port, and 2) any HTTP check should be configurable (either opt-in or
opt-out) in cases where the root of an app isn't expected to return a 200,
of which there are many valid cases. Your proposed work-around in my
opinion is even worse, in that I have to disable any container checking at
all if an app falls outside of what you consider typical.

I think we agree that the best solution for most common apps is to use an
HTTP check, but in order for that to be functional I think the platform
would need to define a new "http" healthcheck type and allow the user to
configure a timeout and expected status code (with defaults of 1 second and
200).

Aaron



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