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.
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.