-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Activator headers getting forwarded prevent scaling from 0 #2234
Labels
area/API
API objects and controllers
area/autoscale
kind/bug
Categorizes issue or PR as related to a bug.
Comments
/assign @scothis |
scothis
added a commit
to scothis/serving
that referenced
this issue
Oct 16, 2018
The activator set the `Knative-Activator-Num-Retries` header on requests it forwards to a starting revsion as well as on responses returned from the activator. When the activator recieves a new request with the `Knative-Activator-Num-Retries` header it immediatly returns a 503. This has the effect of causing a request that hits the activator to fail if the request is triggered from the response that also hit the activator. This PR makes two distinct changes to prevent this situation from recurring: - the request and response headers now use distinct names. The request header is `knative-activator-num-retries`, while the response header is `knative-activator-attempts` - the request header is stripped off the request in the queue-proxy along side the other activator headers Fixes knative#2234 Fixes knative/eventing#523
scothis
added a commit
to scothis/serving
that referenced
this issue
Oct 16, 2018
The activator set the `Knative-Activator-Num-Retries` header on requests it forwards to a starting revsion as well as on responses returned from the activator. When the activator recieves a new request with the `Knative-Activator-Num-Retries` header it immediatly returns a 503. This has the effect of causing a request that hits the activator to fail if the request is triggered from the response that also hit the activator. This PR makes two distinct changes to prevent this situation from recurring: - the request and response headers now use distinct names. The request header is `knative-activator-attempts`, while the response header is preserved as `knative-activator-num-retries` - the request header is stripped off the request in the queue-proxy along side the other activator headers Fixes knative#2234 Fixes knative/eventing#523
knative-prow-robot
pushed a commit
that referenced
this issue
Oct 25, 2018
* Avoid emitting headers that latter reject requests The activator set the `Knative-Activator-Num-Retries` header on requests it forwards to a starting revsion as well as on responses returned from the activator. When the activator recieves a new request with the `Knative-Activator-Num-Retries` header it immediatly returns a 503. This has the effect of causing a request that hits the activator to fail if the request is triggered from the response that also hit the activator. This PR makes two distinct changes to prevent this situation from recurring: - the request and response headers now use distinct names. The request header is `knative-activator-attempts`, while the response header is preserved as `knative-activator-num-retries` - the request header is stripped off the request in the queue-proxy along side the other activator headers Fixes #2234 Fixes knative/eventing#523 * Review feedback * Further indicate the response header is internal
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/API
API objects and controllers
area/autoscale
kind/bug
Categorizes issue or PR as related to a bug.
Expected Behavior
Apps/functions always scale up from 0 when a new request arrives
Actual Behavior
Due to renaming the header used by the Activator in PR #2051 this header now gets forwarded in the eventing message bus and seems to interfere with the scaling up of the next app/function in a message chain.
Steps to Reproduce the Problem
Additional Info
The message on the second channel would look something like this:
It's easy to verify this by using Cloud Pub/Sub as the bus and viewing the messages for the topics directly.
If this is fixed in serving then that would solve the issue knative/eventing#523 reported in eventing.
The text was updated successfully, but these errors were encountered: