This copies the codes and status package from grpc as it is the only references
to the grpc project from ttrpc. This will help ensure that API breaking changes
in grpc do not affect ttrpc.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Since some type's Marshal() on nil will crash runtime, thus
it's should check 'resp' before marshaling on it. If it's
nil, return directly to avoid the server crash.
Signed-off-by: lifupan <lifupan@gmail.com>
when enable go module, go get will update the required version. It is
not supported to run in CI.
More info: https://github.com/golang/go/issues/27643.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
When call server.Close(), server will close all listener and notify
flighting-connection to shutdown. Connections are closed asynchronously.
In TestClientEOF, client can send request into closing-connection. But
the read for reply will return error if the closing-connection is
shutdown.
In this case, we should filter error for client side about `read:
connection reset by peer`.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
To account for 5da5b1f225,
which is part of gRPC v1.23.0 and up, and after which gRPC no longer sets a
Status if no error occured.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Return if client is gone, log all other errors
Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Signed-off-by: Georgi Sabev <georgethebeatle@gmail.com>
Currently the EOF that the server gets when a client connection is
closed is being ignored, which means that the goroutine that is
processing the client connection will never exit. If it never exits
it will never close the underlying unix socket and this would lead
to a file descriptor leak.
Signed-off-by: Georgi Sabev <georgethebeatle@gmail.com>
Adds a new field to the `Request` type which specifies a timeout (in
nanoseconds) for the request. This is propagated on method dispatch as a
context timeout.
There was some discussion here on supporting a broader "metadata" field
(similar to grpc) that can be used for other things, but we ended up
with a dedicated field because it is lighter weight and expect it to be
used pretty heavily as is.... metadata may be added in the future, but
is not necessary for timeouts.
Also discussed using a deadline vs a timeout in the request and decided
to go with a timeout in order to deal with potential clock skew between
the client and server. This also has the side-effect of eliminating the
protocol/wire overhead from the request timeout.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
