My concern is that the HTTP check (mislabeled as "port") would still be the
default and I'd have to expect users to opt out of it per app. It's
confusing and not what users of the platform have come to expect moving from
DEA/IF.

In general, the HTTP checks as a platform owner still make me nervous. They
are nice in theory as long as they are opt-in for the developer, but what
happens when something goes wrong? For example, say I have an app dependent
on a back-end resource (database, web service, etc.) that is down and as a
result my app is returning a friendly error page with a 500 response. With
an HTTP healthcheck my app is now effectively down with an ugly 404 message
from the router as all containers will fail and not correctly respawn
because they will not return a 200 to ever get healthy. Is that a better
user experience than the friendly error page? How long will Diego continue
trying to start the unhealthy containers before it gives up and then
requires developer interaction to start the app again?

To close on this, I think the new story is essential for consistency of the
overall platform and to avoid the issues above, and I would argue strongly
that it should be completed ASAP. Once the improved story is in place then
my customers could opt into an HTTP check with adequate knowledge of the
potential impacts.

Aaron



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