-
Notifications
You must be signed in to change notification settings - Fork 209
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
io.dapr.exceptions.DaprException: RESOURCE_EXHAUSTED: Received message larger than max (5759620 vs. 4194304) #781
Comments
@tiankanghello Can you provide more details on this issue -
|
my java-sdk version 1.4,my jdk version 1.8.0,k8s dapr version 1.8 |
When I call the grpc api. The data can be called normally within 4M. When the data is greater than 4M, this error will be reported |
my java-sdk version 1.4,my jdk version 1.8.0,k8s dapr version 1.8 |
@tiankanghello please take a look at the CLI flag or equivalent Kubernetes annotation for HTTP request size. https://docs.dapr.io/reference/cli/dapr-run/ "--dapr-http-max-request-size" default is 4, for 4MB |
--dapr-http-max-request-size I have configured 100M. The api can accept the request. But when the response comes back. The mistake was reported. |
I guess this error is reported by the grpc package. It is possible that the maximum packet size accepted by the grpc packet is 4194304 bytes |
If this problem can't be solved. I can only compress my data. Then unzip. This is not a good way. Because both the server and client need to be transformed |
@tiankanghello A similar property should be available for okhttp client also |
@tiankanghello we will take a look at this and get back to you on the next steps.... |
I hope you can find the problem as soon as possible, and then give me a reply on how to solve this problem. Thank you. |
@mukundansundar Will this problem be solved or will it not be adjusted in the near future |
When I came across this problem. What should I do to be normal io.dapr.exceptions.DaprException: RESOURCE_EXHAUSTED: Received message larger than max (5759620 vs. 4194304)
The text was updated successfully, but these errors were encountered: