This change replaces github.com/gogo/protobuf with
google.golang.org/protobuf, except for the code generators.
All proto-encoded structs are now generated from .proto files,
which include ttrpc.Request and ttrpc.Response.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
Google's new protobuf code generator only supports protobuf
serialization/deserialization and let other code generators handle
RPC-related aspects.
This new code generator follows the change and can be used with
the new protobuf code generator.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
Changes the TTRPC client logic so that sending and receiving with the
server are in completely independent goroutines, with shared state
guarded by a mutex. Previously, sending/receiving were tied together by
reliance on a coordinator goroutine. This led to issues where if the
server was not reading from the connection, the client could get stuck
sending a request, causing the client to not read responses from the
server. See [1] for more details.
The new design sets up separate sending/receiving goroutines. These
share state in the form of the set of active calls that have been made
to the server. This state is encapsulated in the callMap type and access
is guarded by a mutex.
The main event loop in `run` previously handled a lot of state
management for the client. Now that most state is tracked by the
callMap, it mostly exists to notice when the client is closed and take
appropriate action to clean up.
Also did some minor code cleanup. For instance, the code was previously
written to support multiple receiver goroutines, though this was not
actually used. I've removed this for now, since the code is simpler this
way, and it's easy to add back if we actually need it in the future.
[1] https://github.com/containerd/ttrpc/issues/72
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
gRPC has UNIMPLEMENTED status code that indicates a requested method
is not implemented. However ttrpc was returning codes.NotFound which
could be returned when a request entity was not there.
This fix changes the status code from codes.NotFound to
codes.Unimplemented to disambiguate and be more compatible with gRPC.
Fixes#80.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
This is mostly a copy of the workflow from the github.com/containerd/typeurl
repository. After this we can remove travis.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/sirupsen/logrus/compare/v1.4.2...v1.7.0
logrus v1.7.0 removes dependency on github.com/konsorten/go-windows-terminal-sequences
Features:
* a new buffer pool management API has been added
* a set of `<LogLevel>Fn()` functions have been added
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
ttrpc provides WithOnClose option for user and ttrpc will call the
callback function when connection is closed unexpectedly or the ttrpc
client's Close() method is called. containerd runtime plugin uses it
to handle cleanup the resources created by containerd shim.
But the ttrpc client's Close() is only trigger and the shim's cleanup
resource callback is called asynchronously, which might make part of
resources leaky. There is an example from containerd-runtime-v2 for
runc:
```happy
[Task.Delete goroutine] [cleanupCallback goroutine]
call ttrpc client.Close() -->
read bundle and call runc delete
delete bundle
```
If the cleanupCallback is called after deleting bundle, the callback
will fail to call runc delete. If there is any running processes, the
resource becomes leaky.
```unhappy
[Task.Delete goroutine] [cleanupCallback goroutine]
call ttrpc client.Close() -->
delete bundle
failed to read bundle and call runc delete
```
In order to avoid this, introduces the UserOnCloseWait to make sure that
the cleanupCallback has been called synchronously, like:
```
[Task.Delete goroutine] [cleanupCallback goroutine]
call ttrpc client.Close() -->
wait for callback
read bundle and call runc delete
<-- finish sync
delete bundle
```
Signed-off-by: Wei Fu <fuweid89@gmail.com>
