Details
-
Bug
-
Resolution: Unresolved
-
Major
-
Cheshire-Cat
-
Triaged
-
Yes
Description
We've seen in a couple of cases recently where clients did not drain bytes from streaming requests opened against ns_server.
This is one such case. In this there was 11k items in the message queue and the process showed it was holding onto what looks to be 580 MB of memory.
This is another case. In this case, there were 2k open streaming connections each of which was backed up to the extent of a couple of hundred KB of data.
Fixing this doesn't seem so straightforard. When streaming requests are unhibernated to check to see whether more data should be send on the streaming connection, they could take a look at process memory or message queue length as a proxy for liveness of the client. But it would be good to have some protection here if we can figure it out.