qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (JIRA)" <j...@apache.org>
Subject [jira] Closed: (QPID-2893) Changes to MessageStore interface to support new cluster design.
Date Thu, 07 Oct 2010 13:31:30 GMT

     [ https://issues.apache.org/jira/browse/QPID-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alan Conway closed QPID-2893.
-----------------------------

    Resolution: Invalid

As I'm refining the new cluster design I find that the fit with the MessageStore interface
is becoming strained. It's distorting both the message store interface and the cluster design.
The cluster probably deserves to be called out explicitly rather than hiding behind the store
interface, and separating the two simplifies the situation when both are loaded.

I therefore propose to introduce a new interface for cluster implementations, somewhat similar
to the MessageStore interface but not tied to it.  If in the long run we discover there's
some common abstraction that would be valuable we can refactor.

> Changes to MessageStore interface to support new cluster design.
> ----------------------------------------------------------------
>
>                 Key: QPID-2893
>                 URL: https://issues.apache.org/jira/browse/QPID-2893
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker
>            Reporter: Alan Conway
>            Assignee: Alan Conway
>
> The new cluster design outlined at https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt
proposes to use the MessageStore interface to drive the cluster. This would require some modifications
as outlined below. This JIRA is for discussion/refinement of the changes by anyone interested
in MessageStore implementations.
> *** Add acquire() and release() to MessageStore
> Add two new functions to MessageStore, called when messages are
> acquired/released.  Existing store implementations can implement these
> functions as no-ops.
>     virtual void acquire(TransactionContext* ctxt, const
>                          boost::intrusive_ptr<PersistableMessage>&
>                          msg, const PersistableQueue& queue) = 0;
>     virtual void release(TransactionContext* ctxt, const
>                          boost::intrusive_ptr<PersistableMessage>&
>                          msg, const PersistableQueue& queue) = 0;
> Why: the store needs to know about the acquired status of messages to
> ensure that acquired messages are not dequeued on another member.
> *** Call MessageStore functions for durable *and* non-durable queues/exchanges/messages.
> The broker should call MessageStore functions for all messages,
> exchanges, queues & bindings. Existing store implementations must
> check the durable/persistent flag and ignore calls for non-durable
> objects.
> Why: the cluster replicates both durable and transient objects so
> needs to be called for both.
> *** Support async completion of accept when dequeue completes.
> Interface is already there on broker::Message, just need to ensure
> that store implementations call it appropriately.
> Why: this is a bug currently, we complete accepts immediately on
> issuing the AIO commands without waiting for completion.
> *** Support async completion for declare, bind, delete
> class MessageStore { typedef boost::function<void ()>
>     CompletionCallback;
>     virtual void create(PersistableQueue& queue, const
>                         framing::FieldTable& args, CompletionCallback
>                         onCompletion, ) = 0;
> Existing stores that synchronously complete wiring changes would call
> onCompletion() directly in the create/bind/destroy function.
> Why: The cluster can't safely block till a create, destroy or bind
> call has been replicated, it would risk deadlock.
> *** Chaining MessageStores and multiple async completers.
> Allow multiple MessageStore implementations to be attached to a
> broker, e.g. journal + cluster. Implement MessageStoreChain, a
> MessageStore implementations that delegates to multiple MessageStores.
> MessageStoreChain must arrange for async completion to work correctly:
> i.e.  the action is considered complete when *all* of the registered
> stores have indicated their completion.
> This shouldn't have any impact on the MessageStore interface or
> existing implementations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message