[FIXED] A slow consumer could cause the publisher to block

[kozlovic]

The server reads data from a client from a go routine. When receiving
messages, it checks for matching subscriptions, and if found, would
send those messages from the producer's readLoop.
A notion of "budget" was used to make sure the server does not spend
too much time sending to clients from the producer's readLoop, however,
regardless of how small the budget was, if one of the subscription's
connection TCP buffer was full, a TCP write would block for as long
as the defined write_deadline (which is now 10 seconds).

We are removing this behavior and therefore clients (like it was the
case for other type of connections) will now always notify the
subscriber's writeLoop that data is ready to be sent, but the send
will not occur in the producer's writeLoop.

Resolves #2679

Signed-off-by: Ivan Kozlovic [email protected]

[kozlovic]

@derekcollison I did not completely remove the concept of "budget" since we have a case in the event loop where we want to flush in place (but this is in a "send loop") the last message posted.

Also, although benchmark did not reveal adverse effects, I do believe that this may - in some cases - increase the number of slow consumers by never slowing down the producer (that is, not reading producer's messages and therefore applying back pressure). We will see...

[derekcollison]

LGTM