On 28 June 2011 17:13, Gordon Sim <[email protected]> wrote: > On 06/28/2011 04:10 PM, mick wrote: > >> On Tue, 2011-06-28 at 15:51 +0100, Gordon Sim wrote: >> >> >>> E.g. imagine the group relates to some real world object being >>> modelled >>> and each message contains describes an update >>> >> >> >> To me that situation seems like it should be modeled as a queue. >> > > Fair point, however ... > > > I think it would be very worthwhile in this discussion to figure out at >> what point we feel that a customer ought to opt for a queue rather than >> a message group. >> > > ... I think one of the criteria is how many groups there are and how > dynamic the set of groups is. > > In this example it might be that there are lots and lots of objects, but > only a few processing 'engines'. Further, the exact set of objects might be > dynamic. I don't want to have to tie the processing engines to specific > queues for each object, I want them to adapt to the changing system.
To a certain extent it seem to me that whether it's modelled by multiple queues or a single queue with groups could be seen as an implementation detail within the broker... The user knows what they want, and we just need to provide them with a language for getting that functionality. Certainly from the use cases which have been presented to me for these sort of situations, the number of groups is large, there identities are not known up front, and their lifetimes relatively short... thus the user wants a single stable address from which they can receive their messages... but once they start getting messages for a particular group, they want to receive all messages for that group. A twist is whether they want to interleave messages from different groups on the same consumer... -- Rob
