Virtual byte channels need flow control
Currently, the sending side for a channel will send at max speed with no back pressure. If the receiving side can't keep up, it will run out of memory.
Comments (5)
-
reporter -
reporter Sending side will keep track of amount of data sent but not acked. When a ChannelData message send is requested, it will block if the outstanding data amount is at or over the current window size.
-
reporter - changed version to 1.7.0
-
reporter Reference links on window algorithms:
-
reporter - changed status to resolved
Virtual channel flow control, protocol version 3 (initial work)
Virtual byte channels now implement flow control to throttle the rate of incoming messages to prevent OOMs due to a never-ending receive message queue. Flow control is disabled when connecting to older peers (not implementing protocol version 3).
As indicated above, the protocol version has been incremented to version 3. The changes for proto version 3 are not complete in this merge (see
#16), but they have begun. By default connections to hosts with proto version <3 are no longer allowed. To enable connections to older peers the system propertyintrepid.min_supported_protocol
can be used. For example:-Dintrepid.min_supported_protocol=2
.In addition to VBC flow control, proto 3 aims to optimize and clean up message formats. As a first step, this merge also removes the per-message-type version field in all messages but SessionInit and SessionInitResponse.
Finally, MINA buffer allocation tunables have been added: *
intrepid.mina.encoder.allocate_cached
- When present, the caching allocator will be used rather than the simple allocator. *intrepid.mina.encoder.allocate_size
- Initial size (in bytes) to use for message encode buffers. The initial size used to be 256k but has been reduced to 2k. *intrepid.mina.encoder.allocate_direct
- When present, buffers will allocate as direct buffers.→ <<cset 8b895e4662ad>>
- Log in to comment
To deal with flow a simple "window" mechanism will be added (along with an MTU) to channels.
Message changes:
ChannelInit
ChannelInitResponse
ChannelData
New message type: ChannelDataAck
Other possible addition: an MTU in the session init which specifies the max length that can be sent in any data array. (Would also like to include invokes & returns, which would require fragmenting. So, this is probably best as another issue.