The reason for redelivering messages when a subscription is removed is because other subscriptions may have originally disocunted those messages because they were locked when they came to try and dispatch them.
That's interesting... because with the current code these messages are left on the pending list. What you say makes sense for a better implementation.
The whole Queue dispatch model is not very scalable because each message is being delivered to each subscription - this, I think was done because it made the implementation of exclusive consumer easier. I'm currently moving away from this model - to decide at Queue dispatch time which subscription should get the message - just like a - well a Queue!
I think that makes a lot of sense! I want my application to scale to 32 or 64 consumers hammering away, and with the current implementation, I can't see that happening.
It all sounds great Rob - any rough ideas when this might ready? Let me know and I'll give it a good workout. :)
Cheers, David
