Skip to content
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

Closed
trisberg opened this issue Oct 16, 2018 · 1 comment
Closed

Activator headers getting forwarded prevent scaling from 0 #2234

trisberg opened this issue Oct 16, 2018 · 1 comment
Assignees
Labels
area/API API objects and controllers area/autoscale kind/bug Categorizes issue or PR as related to a bug.

Comments

@trisberg
Copy link
Member

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

  1. create two or more apps
  2. create two channels
  3. create subscription for one app from the first channel and set reply-to to second channel
  4. subscribe the second app to the second channel
  5. wait for both apps to scale to 0
  6. post message to the first channel and watch the first app get scaled up
  7. the second app never scales up even though a message is published to the second channel

Additional Info

The message on the second channel would look something like this:

┌──────┬─────────────────┬───────────────────────────────────────────────────┐
│ DATA │    MESSAGE_ID   │                     ATTRIBUTES                    │
├──────┼─────────────────┼───────────────────────────────────────────────────┤
│ 121  │ 257546630995268 │ Content-Type=text/plain; charset=utf-8            │
│      │                 │ Knative-Activator-Num-Retries=3                   │
│      │                 │ X-B3-Sampled=1                                    │
│      │                 │ X-B3-Spanid=a8cf2769119c0fb4                      │
│      │                 │ X-B3-Traceid=a8cf2769119c0fb4                     │
│      │                 │ X-Request-Id=26a25509-346b-99a2-a458-9cd3340b689b │
└──────┴─────────────────┴───────────────────────────────────────────────────┘

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.

@knative-prow-robot knative-prow-robot added area/API API objects and controllers area/autoscale kind/bug Categorizes issue or PR as related to a bug. labels Oct 16, 2018
@scothis
Copy link
Contributor

scothis commented Oct 16, 2018

/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.
Projects
None yet
Development

No branches or pull requests

3 participants