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 cases

for 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 [3]. 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 [1]) as an improvement over the service-broker based
implementation we tackled.

A possible workaround for our autosleep service broker implementation [2]
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
workaround.

Thanks again,

Guillaume.

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-App-autosleep-support-tp962p989.html
[2] https://github.com/Orange-OpenSource/autosleep
[3]
http://cf-dev.70369.x6.nabble.com/cf-dev-How-can-we-customized-quot-404-Not-Found-quot-td4501.html


*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
404 pagea
- 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.



*Related use-cases:*

*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
code.

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
a 404.

*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
instance.

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 [1] that I'm working on would be able to
dynamically start a previously stopped app in order to save ram during
inactivity.


On Thu, Apr 28, 2016 at 9:32 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Guillaume,

Thank you for sharing your thoughts on these use cases. I can see how
having
a route service field requests for an app, whether the app is up on not,
could be useful.

However, enabling this would significantly change how routes are registered
for apps on Cloud Foundry, and how the router handles the route lookup.
Routes are not currently enabled in the routing tier unless they are mapped
to an app, and only when the app is determined healthy.

You are proposing the router maintains routes which have no backends, and
instead of a failed lookup determining whether a 404 is returned, the
router
should figure out whether a route has any backends or a route service.

I'll chew on your use case and keep my ear out for additional use cases for
maintaining routes with no backends in the routing table.

Best,
Shannon



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Brokered-route-services-only-receiving-traffic-for-routes-mapped-to-started-apps-tp4699p4742.html
Sent from the CF Dev mailing list archive at Nabble.com.