zio-grpc bi-stream НЕ закрывается на стороне сервера после закрытия grpcurl с помощью `Ctrl-C`

Question

Консультация по поводу вызова закрытия двухпотока zio-grpc: когда он будет закрыт? Я использую grpcurl для тестирования bistream, но серверная часть zio-grpc не закрывается немедленно (через некоторое время она закроется).

Я наблюдаю за событием закрытия потока на стороне сервера grpcStream.ensuring. Подробнее:

1. для потока запросов: потребляйте поток запросов в волокне от forkDomain: я предполагаю, что поток запросов grpc будет закрыт, если поток закрыт.

      request
    .mapM { reqItem =>
        // do action here
        UIO(println(s"test get some data from request item: ${reqItem}"))
    }
    .runDrain
    .catchAll(error => ZIO(println(s"find some error: $error")))
    .ensuring {
        UIO(println(s"request stream closed"))
    }
    .forkDaemon

2. для потока ответов на стороне сервера: я предполагаю, что поток ответов grpc будет закрыт, если я закрою созданный экземпляр потока ответов.

          ZStream.fromEffect {
      Queue.unbounded[String].flatMap { queue =>
            ZStream.fromQueue(queue)
      }
    }.flatten
    .ensuring {UIO(println("response stream closed"))}

Код хорошо работает для обработки запроса и ответа, кроме того, он будет вызывать некоторую другую бизнес-логику вensuringно здесь игнорируется для упрощения. Вопросы:

1. Не лучшая практика для обработки двухпотокового закрытого действия с помощьюZStream.ensuringс зио-грпс?
2. Разве по замыслу zio-grpc lantancy не закрывает поток, даже если клиент закрывает поток? В этой ситуации grpcurl закрывается с помощью Ctrl-C, и я заметил, что нижележащий TCP нормально закрывается проверкой FIN req-rsp. Спасибо.

Answer 1

Для дальнейшего тестирования grpcurl закрылсяCtrl-Cвызов потока ответа на стороне сервера будет закрыт первым и немедленно.

Что касается потока запросов на стороне сервера, то он не вызывается, хотя и спустя 5 минут.

Я предполагаю, что клиент обрабатывает жизненный цикл потока запросов, потому что это выходит за рамки основного соединения HTTP2/TCP в представлении уровня gRPC.

В обычном случае это должна быть лучшая практика:

1. закрыть ресурс волокна потока запроса на стороне сервера, если вызвано закрытие потока ответа
2. на стороне сервера следует настроить автоматическое закрытие потока grpc, особенно для потока запросов, если не получен протокол сердцебиения или ping-pang, подобный протоколу на уровне gRPC, чтобы высвободить потенциальный ресурс, обрабатываемый библиотекой gRPC, которой в данном случае является zio-grpc.