Re: Brokered route services only receiving traffic for routes mapped to started apps
Thanks Shannon for your reply and the accurate summary of my proposal.
I'll chew on your use case and keep my ear out for additional use casesfor maintaining routes with no backends in the routing table.
I think some use-cases I detailed previously (reproduced and numbered at
bottom of this email for convenience), could potentially be better
addressed without route services, and therefore qualify as "additional use
cases for maintaining routes with no backends in the routing table":
- a way to recover orphan/lost traffic from a given route mapped to crashed
app. Currently, the only way to get this traffic routed is to register a
wildcard route that gets mapped to a "catch-all" app . However, this
catch-all apps collects orphaned traffic from all the domain, making it
hard to distinct teams in separate spaces/orgs to apply different
processing for different apps. This corresponds to the 1.1 and 1.2
scenarios previously listed, without the additional network hops implied by
the use of a route service (in particular when the app is healthy).
- a 1st class support for autosleep behavior within the platform (see
related thread ) as an improvement over the service-broker based
implementation we tackled.
A possible workaround for our autosleep service broker implementation 
is to register a wildcard route and map it to our autosleep proxy deployed
as an app on CF. The autosleep proxy will then receive all orphan traffic,
including traffic from stopped app.
As this workaround has severe limitations (detailed below), we're eager to
hear whether you feel that "unconditional routing of traffic to route
services" is a likely future direction. This will help us decide whether
we'd wait for this to happen (our current route-service-based
implementation being complete), or rather tackle the wildcard route based
*Limitations of a wildcard based autosleep workaround:*
- all orphaned traffic is sent to the wildcard route, regardless of whether
a stopped app is mapped to the route requiring higher capacity planning for
the autosleep service, and tolerance/hardening to DoS.
- prevents usage of the wildcard route for other purposes such as a custom
- unlike with traffic sent to route services url which may include path
part used to pass some context (in addition to the X-CF-Forwarded-Url
header containing the original request), the wildcard route only forwards
original traffic to the mapped app. Our autosleep app then need to lookup
apps bound to the route at runtime, implying higher load.
*1- returning custom response when app is unavailable (crashed, starting,
stopped, or zero available app instances). *
1.1 For apps returning HTML, this may be custom HTML response (rather than
the default gorouter 404 response page), or specific HTTP response code
such as "503 service unavailable" to suggest client some retries. For route
services dealing with routes serving APIs (e.g. SOAP), a route service may
return a proper SOAP-formatted fault response.
1.2 Multi-site aware route services may choose to redirect users to a route
hosted on a second CF instance through a "307 temporary redirect" status
1.3 A caching service may choose to return (potentially stale) cached
content when the mapped app is in the CRASHED state, rather than returning
*2- Applying side effects upon unavailability of app*
2.1 A SOX-compliant lossless logging service (unlike the potentially lossly
loggregator-based logging), may wish to log full details of the requests
sent to the route, including those that never reached the an available app
2.2 A api gateway route services that would maintain measurements of
performance and availability of the exposed APIs that transit through its
bound routes, would need to receive traffic when bound apps are crashed.
2.3 The autosleep service  that I'm working on would be able to
dynamically start a previously stopped app in order to save ram during
On Thu, Apr 28, 2016 at 9:32 PM, Shannon Coen <scoen(a)pivotal.io> wrote: