On 02/29/2012 03:59 PM, Kim van der Riet wrote:
On Wed, 2012-02-29 at 15:44 +0000, Gordon Sim wrote:
On 02/29/2012 03:21 PM, Kim van der Riet wrote:
The current async store's use of DataTokens corresponds with the second
proposal, ie one DataToken corresponds to a single enqueue. Switching to
a MessageToken will require (at least from the current async store
point-of-view) the maintenance of a map of queues on which this message
is stored and then hang its enqueue-specific data there... This
represents a departure from the current mechanism and an increase in
complexity to the store.
To be clear I am not suggesting that the same MessageToken is used for
enqueues on multiple different queues.
In any case though, you must already be maintaining that map since the
current store interface only has a PersistableMessage with its
persistence ID as the context to an enqueue (and dequeue) along with the
PersistableQueue. Or am I misunderstanding?
Actually, the truth is worse... the current store discards its DataToken
object when the enqueue is complete, then creates a new one and sets it
up to look like an enqueued message when the dequeue occurs. This is
because the current MessageStore interface provides no mechanism for the
store to logically hook its metadata to a message. (This approach was
initially simpler, and thought to be a better choice for performance
than enduring the overhead of a map, though it has never been tested.)
You are correct though, in that if this facility _did_ exist, the store
would have to maintain its own per-message map. I am uncertain if using
an EnqueueToken at interface level would allow this to be skipped
altogether, or if the requirement would simply shift to the broker.
So the crucial question is whether a message related handle can be used
for enqueues on different queues.
The only reason to do so would be to allow a store implementation to
recognise and optimise the case where the same message content was
enqueued on more than one queue.
However stores that do not do any optimisation for this case may prefer
as you point out to have the handle be a queue specific context. That
would require the broker to hold a handle for each 'message-on-queue'.
To support both cases you would need something a little more complex.
E.g. we could have:
MessageHandle* createMessageHandle(DataSource*);
EnqueuedMessageHandle* createEnqueuedMessageHandle(MessageHandle*,
Queuehandle*);
void submitEnqueue(EnqueuedMessageHandle*, TxnHandle*, ResultCallback*,
BrokerContext*);
void submitDequeue(EnqueuedMessageHandle*, TxnHandle*, ResultCallback*,
BrokerContext*);
Here the broker could signal the fact that the same content is used in
multiple enqueues by re-using the same MessageHandle when creating each
EnqueuedMessageHandle. The store implementation could then decide
whether this was something it cared about or not.
I guess that this is probably worth it. It doesn't make the stores more
complicated than they want to be in any real sense and the impact on the
broker is not that high and buys us flexibility for the future.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
