Skip to content
This repository has been archived by the owner on Jun 18, 2022. It is now read-only.

Investigate intermittent 503's #861

Closed
cbron opened this issue Nov 22, 2019 · 4 comments
Closed

Investigate intermittent 503's #861

cbron opened this issue Nov 22, 2019 · 4 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@cbron
Copy link
Contributor

cbron commented Nov 22, 2019

Darren/Dax reported seeing some 503's while clicking around rio services

@cbron cbron added the bug Something isn't working label Nov 22, 2019
@cbron cbron added this to the v0.6.x milestone Nov 22, 2019
@davidnuzik davidnuzik modified the milestones: v0.6.x, v0.7.0 Nov 26, 2019
@cbron cbron modified the milestones: v0.7.0, v0.8.0 Dec 10, 2019
@daxmc99
Copy link
Contributor

daxmc99 commented Dec 23, 2019

no healthy upstream
Reproduction with Chrome:

  • Have a service scaled to zero.
  • Attempt to visit a service endpoint using Chrome with dev tools enabled and disabling the cache
  • While waiting for the request to scale, make another request (refresh).
  • This and subsequent requests will return no healthy upstream and 503 errors.

@rancher-max
Copy link
Contributor

#584 (comment)

@daxmc99
Copy link
Contributor

daxmc99 commented Dec 23, 2019

After working with @rancher-max and @StrongMonkey it looks like the root of the problem is that the service version endpoint $service-v0-on.rio.io is not being populated correctly.

The SSL_SYSCALL error manifests itself on services scaled to zero, when there is no virtual service for that version endpoint. Sometimes, it is dynamically created but the correct behavior should be for the virtual service to always exist even if a service is scaled to zero.

Proposed solution:
All services in Rio should have a version endpoint regardless of scale.

@rancher-max
Copy link
Contributor

This has been fixed in latest master, commit: c0f480fe. The scenario this fixes is, as mentioned above:

  1. Have a single service on an app, and have it with min scale of 0 and max scale of 1 or greater
    2 Wait for the service to be at observed scale of 0, then query the app endpoint (curl is fine)
  2. While the pod is initializing, make more queries to the app endpoint

This was previously returning no healthy upstream on at least one of those subsequent requests, but now returns the correct result:

$ for x in {1..20} ; do curl https://other-as-default.7oign7.on-rio.io ; done
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6
Hi there, I am rio:production6

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants