[
https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-2172 at 6/19/17 4:59 AM:
---------------------------------------------------------
[~rvansa] OK, makes sense not to interfere with the ordering of messages 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.
was (Author: belaban):
[~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)