qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)
Date Thu, 01 Mar 2012 20:57:23 GMT
On Wed, 2012-02-29 at 19:52 +0000, Gordon Sim wrote:
> ...
> 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.

I think this is the best approach, and indeed I intended my sketch to
indicate something like this was my intent (I clearly failed - sorry
about that)

[MessageHandle is called DataHandle and EnqueuedMessageHandle is called
EnqueueHandle in the interface I suggested, although there you do pass
the MessageHandle into the actual operation rather than bundle it into
another Handle. I'm perfectly happy with either approach]


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message