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

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-2172:
--------------------------------

[~rvansa] OK, makes sense not to meddle the ordering of messages as sent by the application.

So the approach needs to be that - once queuing starts - *all* messages will be queued (regardless of size) and only when the queue is drained completely, can we start sending messages directly again. This prevents the P2-P1 scenario above.

The transition to queuing and back needs to be atomic.

> 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)