On 16 February 2014 09:53, Fraser Adams <[email protected]>wrote:
> On 15/02/14 21:55, Robbie Gemmell wrote: > >> [snip] >> >> >> In terms of a 'topic', this needs to be something that supports the >> semantics of the pub-sub model, but there are a number of ways to achieve >> that. We currently have brokers that have models containing 'exchanges' >> that have been used for that historically (in confunction with queues) and >> so that is still the case, but utilising that model for 1.0 can require >> some unecessary hoop jumping (e.g exchanges are made to route messages to >> queues for consumers to receive, meanting that 'receiving from an >> exchange' >> can necessitate creation of temporary subscription queues to give the >> requested semantics) so going forward there is scope for alternative >> behaviours allowed by the 1.0 model. E.g one could represent a topic as a >> 'special' queue which only drops messages once all the consumers have >> passed it. >> >> Robbie >> [snip] >> >> I'd agree with your comment that in 1.0 there are multiple ways to skin > the "topic" cat - indeed as illustrated by the use of Message Selectors to > address Clive's earlier use case, which is somewhat analogous to what you > describe above. However I'd hope that going forward any "alternative > behaviours" would be in addition to the current ones. > > I can see the appeal of a "'special' queue which only drops messages once > all the consumers have passed it. " but from my parochial perspective my > most common use cases involve shared subscription queues that do *not* > autodelete. Don't read into the above as being a fully formed example of something I'm proposing we will implement, it was just a very quick and simplistic example of there being multiple ways to achieve certain things and that some of the existing behaviour doesn't necessarily make sense for 1.0. The particular issue is obviously a lot more complicated when considering things fully, taking into view things like [shared] durable subscriptions, [shared] non-durable subscriptions, selectors, no-local, compatibility, etc etc, but that wasnt really the point of the mail. (not that it really matters, but to make it clearer...the simple example was really talking to the basic non-shared non-durable topic subscription case, with the idea being there wouldnt be any subscription queues at all and instead just the 'topic' and its subscriptions..tagging durable and shared subscriptions on top would obviously need specific handling to achieve the durable and shared aspects) > In other words when a consumer (a logical consumer scaled across multiple > hosts hence the shared queue) has subscribed it continues to be interested > in messages even if it happens to go away for a while and in the current > implementation messages build up on the subscription queue which can be > retrieved when the consumer comes back online. > So in topic terms that would be a shared durable subscription (or if you only had one of those 'logical consumers' its basically just a queue that got messages put on it through some means). > In your example above you could achieve a similar thing with say a large > circular queue, but with every message delivered onto said queue if you get > a mixture of fast and slow producers it's quite possible that the messages > from the slow producer take a disproportionate hit. > > The plus side of your approach is that absolute message order of the > producers gets preserved, which is potentially useful. > > So I think that there are advantages to both but definitely wouldn't want > to lose the existing semantics. > > Cheers, > Frase > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
