[jboss-jira] [JBoss JIRA] (JGRP-2172) Non-blocking flow control

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422756#comment-13422756 ] 

Radim Vansa commented on JGRP-2172:
-----------------------------------

[~belaban] Yes, it is not suitable. This is not about causality, because you don't need to wait for the response; the sender may just push updates (generated in a loop) to the receiver and expect them to be received in the same order. Imagine camera sending frames to a recording device: it generates the frames reading the sensor in a loop, and you don't want to store the frames reordered.

I welcome going all-in for the NB_xFC - that reduces some complexity.

> Non-blocking flow control
> -------------------------
>
>                 Key: JGRP-2172
>                 URL: https://issues.jboss.org/browse/JGRP-2172
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0.4
>
>
> Sending a message through FlowControl (UFC, MFC) should not block if {{Message.Flag.NB_FC}} (non-blocking flow control) is set.
> Instead, the message should be added to a queue (bounded if {{max_size}} > 0, else unbounded). The max queue size is given in bytes, so we can estimate what the memory penalty for reaching that size would be (if bounded).
> The queued messages are sent when credits arrive. TBD: when credits arrive, should blocked threads or queued messages be released first?
> Non-blocking flow control can be used by both external and internal threads.
> If the queue is unbounded, then it is the responsibility of the application (e.g. Infinispan) to make sure the queue doesn't grow to an untenable size.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)