stream: fix the map of streams leak

[wllenyj]

In a connection, streams are added only, but not deleted.
When replying to the last data, delete the stream from map.

And delete operations require concurrency.

Signed-off-by: wllenyj wllenyj@linux.alibaba.com

[dmcgowan]

Ahh yes, thanks

My original thought was to use a buffered channel to mark the removals to be handled in the receive go routine. The motivation being to avoid a locking data structure on the receive path. However, a flood of stream closing which fill up the buffer would likely make that solution unworkable. I'll try to consider other lock free ways we could handle this, but we should get this change in.

[wllenyj]

@dmcgowan thanks.
Streaming is a great project, the logic in it is so complex that it took me a lot of time to understand it, I admire your ability to come up with this stuff :)

[kzys]

Looks good to me.

How did you notice the issue by the way? It would be great if we can write some autometed way to check that this part won't have leaks in future.

[wllenyj]

How did you notice the issue by the way? It would be great if we can write some autometed way to check that this part won't have leaks in future.

I added the test log locally. If we want to cover it by unit test, we need to save streams to serverConn in order to check it at some point later. But it is expected that there will be more modifications.