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.

Sign up for GitHub

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

Jump to bottom

MeshService.LayersQuery broken #5315

Closed
lrettig opened this issue Nov 29, 2023 · 4 comments
Closed

MeshService.LayersQuery broken #5315

lrettig opened this issue Nov 29, 2023 · 4 comments
Labels
area/api technical debt

Comments

@lrettig
Copy link
Member

lrettig commented Nov 29, 2023

Description

It takes a very long time to run, close to a minute for a single layer, probably because it reads all ATX data (presumably the entire active set), probably without caching (no memory issue AFAICT). Then it produces this error:

> grpcurl -plaintext -d '{"start_layer":{"number": 30000}, "end_layer":{"number": 30000}}' localhost:9092 spacemesh.v1.MeshService.LayersQuery
ERROR:
  Code: ResourceExhausted
  Message: grpc: received message larger than max (8411536 vs. 4194304)

Affected code

api/grpcserver/mesh_service.go

This issue appears in commit hash: 6499e01

Related: #5006
@arc0035 arc0035 mentioned this issue Dec 1, 2023
Closed
This was referenced Dec 4, 2023
Closed
Closed
@bobbychen
Copy link

Halo ?how about this issue going on?

@lrettig
Copy link
Member Author

lrettig commented Dec 26, 2023

Halo ?how about this issue going on?

This has been fixed in #5334 and should be merged and released soon!

@lrettig lrettig mentioned this issue Dec 26, 2023
Closed
@poszu
Copy link
Contributor

poszu commented Dec 27, 2023 •
edited
Loading

@lrettig This error:

ERROR:
Code: ResourceExhausted
Message: grpc: received message larger than max (8411536 vs. 4194304)

is on the client (grpcurl) side, not go-spacemesh. The client limits the maximum size of response payload to 4MiB by default. There is a CLI argument to change this:

-max-msg-sz int
        The maximum encoded size of a response message, in bytes, that grpcurl
        will accept. If not specified, defaults to 4,194,304 (4 megabytes).

@lrettig
Copy link
Member Author

lrettig commented Dec 27, 2023

Good catch, thanks for the clarification.

spacemesh-bors bot pushed a commit that referenced this issue Jan 5, 2024
@lrettig @dependabot
@fasmat @pigmej
Hotfix for API queries for activations (#5334)
60ef614 
Modify `MeshService.LayersQuery` to return ONLY the single, canonical block for each queried layer. Fixes performance issues for now by not querying any activations, proposals, etc.

Modify `MeshService.AccountMeshDataQuery` not to query activations to prevent memory/CPU bomb

## Motivation
Closes #5315
Closes #5006

## Changes
- Add method to mesh to return single, valid, applied block for a given layer
- Modify `MeshService.LayersQuery` to use this new method
- Additionally, remove query for activations (leave this empty for now)
- Modify `MeshService.AccountMeshDataQuery` not to query activations

## Test Plan
Tests updated

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed


Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matthias Fasching <[email protected]>
Co-authored-by: Jędrzej Nowak <[email protected]>
spacemesh-bors bot pushed a commit that referenced this issue Jan 8, 2024
@lrettig @dependabot
@fasmat @pigmej
Hotfix for API queries for activations (#5334)
295d22e 
Modify `MeshService.LayersQuery` to return ONLY the single, canonical block for each queried layer. Fixes performance issues for now by not querying any activations, proposals, etc.

Modify `MeshService.AccountMeshDataQuery` not to query activations to prevent memory/CPU bomb

## Motivation
Closes #5315
Closes #5006

## Changes
- Add method to mesh to return single, valid, applied block for a given layer
- Modify `MeshService.LayersQuery` to use this new method
- Additionally, remove query for activations (leave this empty for now)
- Modify `MeshService.AccountMeshDataQuery` not to query activations

## Test Plan
Tests updated

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed


Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matthias Fasching <[email protected]>
Co-authored-by: Jędrzej Nowak <[email protected]>
spacemesh-bors bot pushed a commit that referenced this issue Jan 16, 2024
@lrettig @dependabot
@fasmat @pigmej @kacpersaw
Hotfix for API queries for activations (#5334)
813d26d 
Modify `MeshService.LayersQuery` to return ONLY the single, canonical block for each queried layer. Fixes performance issues for now by not querying any activations, proposals, etc.

Modify `MeshService.AccountMeshDataQuery` not to query activations to prevent memory/CPU bomb

## Motivation
Closes #5315
Closes #5006

## Changes
- Add method to mesh to return single, valid, applied block for a given layer
- Modify `MeshService.LayersQuery` to use this new method
- Additionally, remove query for activations (leave this empty for now)
- Modify `MeshService.AccountMeshDataQuery` not to query activations

## Test Plan
Tests updated

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed


Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matthias Fasching <[email protected]>
Co-authored-by: Jędrzej Nowak <[email protected]>
Co-authored-by: Kacper Sawicki <[email protected]>
kacpersaw added a commit that referenced this issue Jan 16, 2024
@lrettig @dependabot
@fasmat @pigmej @kacpersaw
Hotfix for API queries for activations (#5334)
a8ce8e7 
Modify `MeshService.LayersQuery` to return ONLY the single, canonical block for each queried layer. Fixes performance issues for now by not querying any activations, proposals, etc.

Modify `MeshService.AccountMeshDataQuery` not to query activations to prevent memory/CPU bomb

## Motivation
Closes #5315
Closes #5006

## Changes
- Add method to mesh to return single, valid, applied block for a given layer
- Modify `MeshService.LayersQuery` to use this new method
- Additionally, remove query for activations (leave this empty for now)
- Modify `MeshService.AccountMeshDataQuery` not to query activations

## Test Plan
Tests updated

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed


Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matthias Fasching <[email protected]>
Co-authored-by: Jędrzej Nowak <[email protected]>
Co-authored-by: Kacper Sawicki <[email protected]>
@kacpersaw kacpersaw mentioned this issue Jan 16, 2024
Merged
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/api technical debt
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Merged by Bors] - Hotfix for API queries for activations spacemeshos/go-spacemesh
3 participants
@lrettig @poszu @bobbychen