Everything you described about the design RPC service looks reasonable. But
we may need more information to find out why all RPCs are accidentally
canceled.
Is each client an independent ClientConn, or one stream from the same
ClientConn (I assume independent ClientConn because you said it maintains
its own connection).
Can you provide more details about what's done in the RPC service handler?
How do you deal with the stream when RPC finishes?
If you could come up with a small example to reproduce this, it would also
be very helpful.
Thanks,
Menghan
On Monday, May 15, 2017 at 4:56:15 AM UTC-7, mbi wrote:
>
>
> Hi,
>
> We are using protobuffers and Go version of gRPC to implement
> communication layer in the library we are building. Communication-wise the
> situation in our case is that we have multiple (possibly concurrent)
> clients and a server. We are using bidirectional streams between clients
> and the server, as we want a "ping-pong like" behavior where a series of
> requests and responses has to flow between a specific client and a server
> for the RPC service to successfully complete - we can think of it as a sort
> of a session or a transaction.
>
> The RPC service is defined as follows:
>
> service MyProtocol {
> rpc ExecuteProtocol (stream Message) returns (stream Message) {}
> }
>
> For the above service, a series of 6 messages of type Message are
> transferred, something like this: client_request_1, server_response_1,
> client_request_2, server_response_2, client_request_3, server_response_3.
>
> We fire up a gRPC server like this:
>
> grpcServer := grpc.NewServer(grpc.MaxConcurrentStreams(math.MaxUint32))
> pb.RegisterProtocolServer(grpcServer, NewMyProtocolServer())
> grpcServer.Serve(listener)
>
> And then we want to test with several concurrent clients with the help of
> goroutines, like this:
> var wg sync.WaitGroup
> wg.Add(n)
> for i := 0; i < n; i++ {
> defer wg.Done()
> go runMyProtocolClient()
> }
> wg.Wait()
>
> When we run only one client, the whole "protocol" (e.g. our sequence of
> requests and responses in a given order) executes perfectly and without
> errors. If we run several clients sequentially, everything is OK too - all
> clients finish successfully, and the server stays alive listening for
> further requests. However, when testing with several concurrent clients,
> this is what happens: the server *at first* seems to be able to handle
> requests from all of the clients, but as soon as some client successfully
> finishes, the server exits with error: An error ocurred: rpc error: code
> = Canceled desc = context canceled. All other clients subsequently get
> the EOF error and exit.
>
> Each of our clients maintains its own connection to the gRPC server (this
> is on purpose, as we want to simulate clients on different physical nodes)
> as well as its own client stream. We are passing context.Background() to
> the client's ExecuteProtocol call, and the client never explicitly closes
> either its stream, or its connection to the gRPC server.
>
> Can anyone help us with this? Could this be due to an issue in our design
> of the RPC service, since we assumed that the server can maintain several
> concurrent streams for separate clients? We're all fairly new to Go and
> gRPC, and I hope this question is not too generic - implementation of
> MyProtocolServer and MyProtocolClient was intentionally left out here. I
> will, of course, provide more details and code if you think it will help.
>
> Thanks in advance!
> Best regards
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/9bde0cb3-7045-40e5-b47c-c3ced0bdf96f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
