You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2012/03/01 21:57:23 UTC
Re: Review Request: Develop Asynchronous Store Interface for Qpid
(v.2)
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]
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Review Request: Develop Asynchronous Store Interface for Qpid
(v.2)
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2012-03-02 at 11:26 -0500, Alan Conway wrote:
> On 03/02/2012 11:15 AM, Andrew Stitcher wrote:
> > On Fri, 2012-03-02 at 10:58 -0500, Alan Conway wrote:
> >> ...
> >>
> >> 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
> >
> > I said not to take the pointers too literally. The important point was
> > to avoid needing to pull in definitions for the Handles - our compile
> > times are horrendous already can we avoid pulling in any more
> > unnecessary header files?
> >
>
> IMO that would be a _necessary_ header file.
> ~/qpid/qpid/cpp/include/qpid/messaging/Handle.h contains 19 lines of code, I
> don't think compilation time is really a consideration in a design decision
> between automated or manual memory management.
I agree.
A
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Review Request: Develop Asynchronous Store Interface for Qpid
(v.2)
Posted by Alan Conway <ac...@redhat.com>.
On 03/02/2012 11:15 AM, Andrew Stitcher wrote:
> On Fri, 2012-03-02 at 10:58 -0500, Alan Conway wrote:
>> ...
>>
>> 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
>
> I said not to take the pointers too literally. The important point was
> to avoid needing to pull in definitions for the Handles - our compile
> times are horrendous already can we avoid pulling in any more
> unnecessary header files?
>
IMO that would be a _necessary_ header file.
~/qpid/qpid/cpp/include/qpid/messaging/Handle.h contains 19 lines of code, I
don't think compilation time is really a consideration in a design decision
between automated or manual memory management.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Review Request: Develop Asynchronous Store Interface for Qpid
(v.2)
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2012-03-02 at 10:58 -0500, Alan Conway wrote:
> ...
>
> 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
I said not to take the pointers too literally. The important point was
to avoid needing to pull in definitions for the Handles - our compile
times are horrendous already can we avoid pulling in any more
unnecessary header files?
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Review Request: Develop Asynchronous Store Interface for Qpid
(v.2)
Posted by Alan Conway <ac...@redhat.com>.
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