Problem description
When using gRPC over Named pipes on Windows (IPC), while also firing requests continuously using multiple async requests for over 30 minutes, the connection eventually drops and never recovers. Another important detail is that I use only streaming requests with the server.
This is the actual logs that I get
[electron] D 2024-01-16T19:01:17.114Z | v1.9.13 25544 | connectivity_state | (6) unix:////./pipe/32ed9f96fe90c717 IDLE -> IDLE
[electron] D 2024-01-16T19:01:18.184Z | v1.9.13 25544 | channel | (6) unix:////./pipe/32ed9f96fe90c717 Idle timer triggered after 1800000ms of inactivity
[electron] D 2024-01-16T19:01:18.185Z | v1.9.13 25544 | connectivity_state | (6) unix:////./pipe/32ed9f96fe90c717 IDLE -> IDLE
[electron] [2024-01-16T14:01:20] INFO Failed to scan file: Error: Failed to connect before the deadline. 4 attempts left.
I have traced the issue back to the property grpc.client_idle_timeout_ms, and I believe this issue might be linked to this function.
I have tried using tcp instead of named pipes and it works without any problem.
Reproduction steps
It is very difficult to give exact reproduction steps, as I have no idea what might be causing this. I have a huge amount of code around it, I think that someone with knowledge of the code might better understand why my connection is detected as idle even though I'm using it like crazy for streaming requests. Is it possible that streaming requests don't count as requests and that the connection timeout is not reset ?
Environment
- Windows 11, AMD64
- Node version 18.16
- Node installation method = Choco
- If applicable, compiler version [e.g. clang 3.8.0-2ubuntu4]
- Package name and version =
@grpc/grpc-js@1.9.13
Problem description
When using gRPC over Named pipes on Windows (IPC), while also firing requests continuously using multiple async requests for over 30 minutes, the connection eventually drops and never recovers. Another important detail is that I use only streaming requests with the server.
This is the actual logs that I get
I have traced the issue back to the property
grpc.client_idle_timeout_ms, and I believe this issue might be linked to this function.I have tried using
tcpinstead ofnamed pipesand it works without any problem.Reproduction steps
It is very difficult to give exact reproduction steps, as I have no idea what might be causing this. I have a huge amount of code around it, I think that someone with knowledge of the code might better understand why my connection is detected as
idleeven though I'm using it like crazy for streaming requests. Is it possible that streaming requests don't count as requests and that the connection timeout is not reset ?Environment
@grpc/grpc-js@1.9.13