On Tue, 2011-06-28 at 16:13 +0100, Gordon Sim 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.
OK -- so in general, queues should be used if (1) their identities are known at start-up, or (2) their number is relatively stable over the life of the app message groups should be used if (1) their existence and numbers are not known in advance, or (2) they may appear and disappear rapidly When message groups *are* used, the Queue that they are sent through represents some stable aspect of the message, while the Group represents a transient aspect. For example, a traffic management system might have a queue called TrafficAccidentQueue -- but each individual accident is represented by a separate MessageGroup within that queue. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
