The method_handler will hang until the container exit.
When restart containerd, then the ttrpc client closes, new ttrpc client will create new client_handler thread.
But the old client_handler thread , response thread and task wait method_handler thread will leak.
How can it be improved?
method_handler threads read message from connection fd and handle request individually.
Both recv(fd) and handle request logic are one thread,the handle request logic hang, the thread will never reach recv(fd), this thread will never get socket disconnected error.
Maybe we can add a channel rx in TtrpcContext, and the user can realize client disconnected by get RecvError from rx.recv.
[ ] move read message logic to response thread, the new response thread (named mailroom thread temporarily) will be in charge of reading request and sending response.
[ ] use request channel to deliver task between mailroom thread and method_handler thread.
[ ] use a signal channel to deliver cancel signal between mailroom thread and method_handler thread.
Another different way, can we find a way to check fd in TtrpcContext to get socket status ?
@Tim-Zhang @fuweid
Which feature do you think can be improved?
We need a mechanism which can help
method.handler
to realize the client has been closed in sync ttrpc scenario, likecontext.Done
in golang ttrpc.Current implementation in sync ttrpc server:
In containerd task wait scenario, like https://github.com/containerd/containerd/blob/f7f2be732159a411eae46b78bfdb479b133a823b/pkg/process/init.go#L212
The
method_handler
will hang until the container exit. When restart containerd, then the ttrpc client closes, new ttrpc client will create newclient_handler
thread. But the oldclient_handler
thread , response thread and task waitmethod_handler
thread will leak.How can it be improved?
method_handler
threads read message from connection fd and handle request individually. Bothrecv(fd)
and handle request logic are one thread,the handle request logic hang, the thread will never reachrecv(fd)
, this thread will never getsocket disconnected
error.Maybe we can add a channel rx in
TtrpcContext
, and the user can realize client disconnected by getRecvError
fromrx.recv
.method_handler
thread.method_handler
thread.Another different way, can we find a way to check fd in
TtrpcContext
to get socket status ? @Tim-Zhang @fuweid