qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)
Date Fri, 02 Mar 2012 15:58:25 GMT
On 03/01/2012 03:57 PM, Andrew Stitcher wrote:
> 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 am not keen on using plain pointers in the API, they make memory management 
ambiguous and error prone. If we don't want to use boost, we should implement 
our own ref-counting smart pointers for the API. We already have one such 
implementation for the Handles in the qpid::messaging API we could use that or 
duplicate it if we don't want to have dependencies from store plugins on the 
messaging API

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


Mime
View raw message