You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in paritytech/substrate#9458, there are cases where the response can be quite huge (for tracing requests) and would lock the rpc thread by calling the json formatter.
A possibility is to offload the serialization into a separate thread. This might add additional cost for small payload so benchmarking it would probably be a good idea before doing the switch.
The text was updated successfully, but these errors were encountered:
@crystalin#523 will allow you to register a blocking method, which executes in entirety (including JSON serialization) to a dedicated thread. Would that solve this for you?
Note: This is only enabled for synchronous methods, there is a way to make it work with async methods, but it requires jumping through some hoops and is potentially a footgun if at any point in the async workflow one tries to interact with the main async tokio reactor (read: it would panic in that scenario).
I believe it would solve it yes, as the case where the thread.
Also curious, is the thread handling the query also the thread that must handle the response (Like it is on the RPC module used by Substrate) ?
As mentioned in paritytech/substrate#9458, there are cases where the response can be quite huge (for tracing requests) and would lock the rpc thread by calling the json formatter.
A possibility is to offload the serialization into a separate thread. This might add additional cost for small payload so benchmarking it would probably be a good idea before doing the switch.
The text was updated successfully, but these errors were encountered: