-
Notifications
You must be signed in to change notification settings - Fork 17
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
Request timed out causing meteor instances to be restarted #753
Comments
We need to improve logging since production doesn't appear to log requests right now. Did we pull out of #631 on prod? Wondering why the logs are not on one line. https://media.dev.unee-t.com/2019-04-09/case-dev-vs-prod-logging.mp4 |
If NodeJS locks up and gets killed, there is a some time before it comes back online. This could be expedited by #750 since this proposal would avoid the npm install stage in our current Docker image. |
We reproduced the problem locally in the sense we see Meteor taking a very long time to process a HTTP.call
MEFE says 74s and Bugzilla below says half a second. This is the crux of the problem.
|
Since getting things running locally, we know it's not a DevOps issue. It appears to be something to do with how caseNotifications are read causing a huge delay. @nbiton is working on a fix. |
this shoudl now be fixed thatnks to throttling and the implementation of unee-t/bz-database#129 |
https://media.dev.unee-t.com/2019-04-09/request-timed-out.mp4
Meteor instances in production seem to get stuck and fail to respond to health checks.
The text was updated successfully, but these errors were encountered: