Hello!

On Fri, Aug 10, 2018 at 03:10:11AM -0400, hunterqin wrote:

> I found the problem.
> I used the wireshark to analyse the packets between nginx server and grpc
> server and I found that in the last packet from grpc server to nginx client,
> there are five frames,SETTINGS, HEADERS, DATA, HEADERS, WINDOW_UPDATE. The
> second HEADERS set the 'end_stream' and ngx_http_grpc_filter checked it
> (about the 2100th line in the ngx_http_grpc_module.c)
> if (ctx->end_stream) {
> u->length = 0;
>
> if (ctx->in == NULL
> && ctx->out == NULL
> && ctx->output_closed
> && b->last == b->pos)
> {
> u->keepalive = 1;
> }
>
> return NGX_OK;
> }
> everthing is true but b->last == b->pos
> because there is still a WINDOW_UPDATE frame in buffer and the difference
> between b->last and b->pos just is the length of WINDOW_UPDATE frame.
> That's why keepalive in the upstream not work, it is not set by the grpc
> module.
> Please check the bug. The keepalive problem also happens between grpc client
> and nginx but it is not so serious like this one but it needs your
> attention, too.

With gRPC, much like with other protocols, connections are only
preserved in keepalive cache if there are no pending frames to be
sent or processed when the request is complete. It is expected
that some connections might be closed if there are occasional
pending frames.

If you see keepalive not working for you at all, this might be
because of unfortunate behaviour of your gRPC server. If this is
indeed the case, please provide more details about the gRPC
library you are using and the gRPC server code. An example code
gRPC backend server would be ideal.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx