[jboss-jira] [JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full

Bela Ban (Jira) issues at jboss.org
Fri Mar 27 04:02:48 EDT 2020


    [ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010788#comment-14010788 ] 

Bela Ban commented on JGRP-2462:
--------------------------------

{quote}
Wouldn't you also have to implement explicit congestion notification as well, at least from the transport to xFC, for RED/Blue to work?
{quote}
This could quickly become too complex... The xFC protocol at the sender still subtracts the credits for a message M even if M ends up getting dropped by RED, so when the sender runs out of credits, it will block until new credits have been received. This is similar to TCP in which dropped packets slow down the sender.

{quote}
Also, would you have a single RED/Blue instance or all the members, or would each member get a separate instance, so that when a node is really slow, messages can still be sent normally to other nodes? I was thinking of JGRP-2463 and the coordinator having more load with RELAY2.
{quote}
For now, I'll experiment with a single {{RED}} instance for _all_ members. 

> TransferQueueBundler: drop messages if queue is full
> ----------------------------------------------------
>
>                 Key: JGRP-2462
>                 URL: https://issues.redhat.com/browse/JGRP-2462
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block.
> This can happen for example when the TCP {{send}} blocks due to a full send-window.
> Retransmission requests and responses compound the problem when the TQB's queue is full.
> Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first.
> Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter.
> Look at random early detection )\[1\]) for inspiration.
> \[1\] https://en.wikipedia.org/wiki/Random_early_detection



--
This message was sent by Atlassian Jira
(v7.13.8#713008)


More information about the jboss-jira mailing list