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

Serving not correctly report readiness check if there is no activity #190

Closed
pradithya opened this issue May 4, 2019 · 0 comments · Fixed by #191
Closed

Serving not correctly report readiness check if there is no activity #190

pradithya opened this issue May 4, 2019 · 0 comments · Fixed by #191

Comments

@pradithya
Copy link
Collaborator

pradithya commented May 4, 2019

Expected Behavior

Serving should report correct readiness check even if there are no request coming in.

Current Behavior

If there is no request coming in to serving the ConnectivityState to Core become ConnectivityState.IDLE after 30 minutes. The readiness check currently only consider serving to be ready when ConnectivityState to core is in ConnectivityState.READY.

The Pod is still considered READY though since connectivity to core will return to ConnectivityState.READY in subsequent readiness check, unless readinessProbe. failureThreshold is set to 1 (default is 3)

Steps to reproduce

Run Feast and let it idle for more than 30 minutes. Serving pod will produce following error log every 30 minutes:

2019-04-20 17:00:10.686 ERROR feast-serving-758cc48bb5-l74r6 --- [nio-8080-exec-6] f.s.h.HealthHttpService                  : not ready: unable to connect to core service
2019-04-20 17:30:20.686 ERROR feast-serving-758cc48bb5-l74r6 --- [nio-8080-exec-8] f.s.h.HealthHttpService                  : not ready: unable to connect to core service

Specifications

  • Version: 0.1.0, 0.1.1
  • Subsystem: serving

Possible Solution

Consider ConnectivityState.IDLE as ready state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant