Yes, that is a correct description of the state of things. A way to improve this is to introduce flow control in the application layer, where consumers only receive buffers when they have buffers available. They could announce on the channel how many buffers they have before they receive anything. This way there will be no blocking of the channel and we could actually multiplex more consumers over the same channel.
The implementation is probably a little tricky, but if you want to work on this and have time to actually do it, we can think about the details. :-) Would you be interested? If yes, let's schedule a Hangout where we brainstorm about the solution and how to implement it. Ideally, we would come up with a design document, which we share on the mailing list and then we continue implementing it. I currently only have time to act as a guide/mentor and you would have to do most of the implementation. – Ufuk On Mon, May 23, 2016 at 5:40 AM, wangzhijiang999 <wangzhijiang...@aliyun.com> wrote: > Hi, > > I am confused with sharing tcp connection for the same connectionID, if > two tasks share the same connection, and there is no available buffer in the > local buffer pool of the first task , then it will set autoread as false > for the channel, but it will effect the second task if it still has > available buffer. So if one of the tasks no available buffer , all the other > tasks can not read data from channel because of this. My understanding is > right? If so, are there any improvements for it? Thank you for any help! > > > > >
