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
I noticed weird behavior of the grpc_client in my application.
I have a client-server application which uses grpc_client:unary(...) function and external msg encoder.
Unfortunately, after sending a large amount of messages in parallel, the server application receives streams in wrong sequence which causes a crash:
1 -> 3 -> 5 -> 7 -> 9 -> 11 -> 15 -> 19 -> 13 -> 21 -> crash
and this is incompatible with rfc7540.
I noticed that grpc_client reserves the new stream ID and after that stats to process message content, including encoding the message(grpc_client_stream.erl). If the sending message is very big it will be encoded(and send) later than the message from the next one streamID. In my opinion this is a bug.
The text was updated successfully, but these errors were encountered:
Hi,
I noticed weird behavior of the grpc_client in my application.
I have a client-server application which uses grpc_client:unary(...) function and external msg encoder.
Unfortunately, after sending a large amount of messages in parallel, the server application receives streams in wrong sequence which causes a crash:
1 -> 3 -> 5 -> 7 -> 9 -> 11 -> 15 -> 19 -> 13 -> 21 -> crash
and this is incompatible with rfc7540.
I noticed that grpc_client reserves the new stream ID and after that stats to process message content, including encoding the message(grpc_client_stream.erl). If the sending message is very big it will be encoded(and send) later than the message from the next one streamID. In my opinion this is a bug.
The text was updated successfully, but these errors were encountered: