-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
ui: Network diagnostics debug page hung indefinitely #20683
Comments
If you want to try reproducing locally, you can download the file in the linked comment, rename it to |
For what it's worth, I think the network is working ok. The lack of up-replicating appears to be caused by something else. |
BramGruneir
added a commit
to BramGruneir/cockroach
that referenced
this issue
Dec 18, 2017
The invalidation time for cashed data reducers was used for both invalidation and as the api timeout. This change turns that into two different optional values. Also included in this change: - Set all debug pages to use KeyedCacheDataReducers instead of CachedDataReducers which fixes a number of bugs in which parts of the debug pages might not update. - Set the invalidation period for all debug pages to 0, so they are already reloaded intead of using cached values. - Set the timeout for all debug pages to be 1m or greater (depending on the expected lenght of the request). Fixes: cockroachdb#20634, cockroachdb#19920, cockroachdb#20683 Release note: None
BramGruneir
added a commit
to BramGruneir/cockroach
that referenced
this issue
Dec 18, 2017
The invalidation time for cashed data reducers was used for both invalidation and as the api timeout. This change turns that into two different optional values. Also included in this change: - Set all debug pages to use KeyedCacheDataReducers instead of CachedDataReducers which fixes a number of bugs in which parts of the debug pages might not update. - Set the invalidation period for all debug pages to 0, so they are already reloaded intead of using cached values. - Set the timeout for all debug pages to be 1m or greater (depending on the expected lenght of the request). Fixes: cockroachdb#20634, cockroachdb#19920, cockroachdb#20683 Release note: None
BramGruneir
added a commit
to BramGruneir/cockroach
that referenced
this issue
Dec 18, 2017
The invalidation time for cashed data reducers was used for both invalidation and as the api timeout. This change turns that into two different optional values. Also included in this change: - Set all debug pages to use KeyedCacheDataReducers instead of CachedDataReducers which fixes a number of bugs in which parts of the debug pages might not update. - Set the invalidation period for all debug pages to 0, so they are already reloaded intead of using cached values. - Set the timeout for all debug pages to be 1m or greater (depending on the expected lenght of the request). Fixes: cockroachdb#20634, cockroachdb#19920, cockroachdb#20683 Release note: None
BramGruneir
added a commit
to BramGruneir/cockroach
that referenced
this issue
Dec 18, 2017
The invalidation time for cashed data reducers was used for both invalidation and as the api timeout. This change turns that into two different optional values. Also included in this change: - Set all debug pages to use KeyedCacheDataReducers instead of CachedDataReducers which fixes a number of bugs in which parts of the debug pages might not update. - Set the invalidation period for all debug pages to 0, so they are already reloaded intead of using cached values. - Set the timeout for all debug pages to be 1m or greater (depending on the expected lenght of the request). Fixes: cockroachdb#20634, cockroachdb#19920, cockroachdb#20683 Release note: None
Fixed by #20828 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm running a 1.1.2 cluster using the Docker Compose file from #20241 (comment). The cluster is in a somewhat bad state judging by the fact that no ranges are being up-replicated, so I decided to try to load the
/#/reports/network
page to see if networking was involved, but the page got stuck here for minutes:I'm not sure whether it's related to the network being broken, but reloading the page does not fix it. I talked with @BramGruneir about a similar issue on a build from head last month, but the assumption then was that it was related to bad protobuf generation. This is happening on our 1.1.2 Docker image, so it's more serious.
The text was updated successfully, but these errors were encountered: