On 07/25/2011 02:46 PM, Alan Conway wrote:
Response in line
[snip]
Ah, yes - sorry. The lifetime of the group's state depends on the type
of "Policy" that is being used (see below). For the "Sequenced
Consumers" policy - which is what I was thinking of in my last reply -
the broker doesn't need to maintain state across all messages of the
group. With that policy, the state can be dropped once there are no
more messages for that group present in the broker.
Again I don't get that. You're putting group boundaries at unpredictable
arbitrary points depending on relative speed of producer/consumer. The
producer may send the first N messages of a group containing N+M
messages, then the consumer consumes the first N messages. Now the queue
is empty so the next M messages are considered a new group, where N is
impossibly to predict in advance. So you randomly cut up the groups.
Cutting up the groups doesn't matter though. The requirement here is
only that the messages be processed in order.
We only need to hold state regarding groups in order to prevent delivery
of messages to one consumer when earlier messages of the same group have
been given to another consumer who has not yet indicated that they have
been processed.
For the other proposed policy - Exclusive Consumer - then the group
state would be associated with a particular Consumer instance, and
remain present as long as the Consumer exists. So in that case, yes -
there is the potential that an unbounded number of group states could
exist without some kind of reclaim strategy. And end-of-group marker
could be used, but that wouldn't prevent a DOS by a misbehaving app
that creates endless groups w/o setting the end marker. Perhaps a hard
max-groups-per-Consumer limit, or a TTL for idle groups?
I'm not so worried about that, it's no worse than the fact that a client
can create a huge number of of sessions or consumers etc. Solving that
family of DOS attacks is a separate issue I think.
I agree. I'd leave worrying about this for a later stage.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
