ConsumerWindowSizeTest::testNoWindowRoundRobin is bogus?

[timfox]

Test is failing quite a lot, and looks bogus to me.

I don't see how we can guarantee round robin. With large messages if the consumer is still busy delivering a large message then it will be busy and the message will go to the other consumer.

I'm commenting this out for now.

The only reason it was passing before, was because the entire large message was previously delivered in one call of the handle() method with the previous broken implementation- very bad - this would have tied up the delivery thread for a long time.

[clebert.suconic]

I thought I had already commented out the method.


But it was using the promptDelivery thread on purpose. I remember this was another thing we discussed back then. As long as flow control would give up delivery.

If we deliver it in another thread, we can't guarantee order also. You will be delivering another message before the previous message was completed.

[timfox]

If we deliver it in another thread, we can't guarantee order also. You will be delivering another message before the previous message was completed.

How did you reach that conclusion?

[clebert.suconic]

Say, you sent 100 LargeMessages. There are 100 Consumers.

You will have all the 100 Consumers receiving the message almost immediately. First: You could flood the server here, having too many packets on the Channel waiting to be delivered.

Also, the second message will be delivered before the previous one was finished.

Those are the two reasons why the delivery of the large message was done inside the promptDelivery thread until it was out of credits.

[timfox]

Say, you sent 100 LargeMessages. There are 100 Consumers.

You will have all the 100 Consumers receiving the message almost immediately. First: You could flood the server here, having too many packets on the Channel waiting to be delivered.

Also, the second message will be delivered before the previous one was finished.

Those are the two reasons why the delivery of the large message was done inside the promptDelivery thread until it was out of credits.

I have no idea what you are talking about here.

[clebert.suconic]

never mind: I was thinking about a scenario where you could flood the server.

Say, you send 100 messages. You could have 100 messages being delivered simultaneously consuming resources on the server.

But the Session executor is a thread pool, so that's not problem.

[timfox]

Not only is it a thread pool, it is an ordered executor too, so I don't think any of your assertions hold water.