qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: New User JMS API Questions
Date Sun, 16 Feb 2014 09:53:04 GMT
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. 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.

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message