Logic of deliver() duplicated in directDeliver()

[timfox]

I was just looking at the code in QueueImpl to do some optimisations for delivery and I noticed that most of the logic for deliver() has also been duplicated in the directDeliver() method. (It didn't used to be like that).

Any good reason why this was done - it's very ugly.

[ataylor]

I can't see any, I would change it

[timfox]

I think I'm going to do a refactoring tomorrow.

Also, there's another issue here.

The current delivery algorithm assumes that the distributor will eventually return all consumers - and it won't exit the loop until this occurs.

This will work for the RoundRobinDistributor which is guaranteed to return all consumers after N calls, where N is the number of consumers in total.

However for other conceivable distributors, e.g. one that always returns the first member, this won't work and the algo will spin in an infinite loop.

I am now thinking is there any value in allowing different distributions other than round robin?

If not, then we can remove the Distributor altogether and let the QueueImpl manage a list of consumers directly. This will simplify the delivery logic significantly and allow us to remove the busy and null consumer sets.

wdyt?

[ataylor]

That's a good point. I cant think of any other kind of distributor, i would remove it and simplify the code.

[mural74]

I guess that a distributor that takes into consideration the latency of the consumer would be a possible kind of distributor. Not sure how hard it would be to implement, though.