qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Giusti (JIRA)" <j...@apache.org>
Subject [jira] Updated: (QPID-2921) c++ broker: Improvements to asynchronos completion
Date Tue, 04 Jan 2011 20:27:50 GMT

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

Ken Giusti updated QPID-2921:

    Attachment: msg.patch

This patch attempts to solve just the asynchronous message completion problem.  It modifies
the reference counter in a persistable message to provide a callback that indicates whether
the completion is occurring in the context of the receive path.

Additionally, it updates execution.sync to pend completion on outstanding asynchronous messages.

Issues I have with this patch:

1) there's no clean way to pass the completion status from the SessionAdapter layer back to
the SessionState for a given command.  Ideally, this could be done via the invoker result,
but the SessionAdapter's handlers don't have access to the invoker result in order to set

2) Message transfer is currently not represented by an "incomplete command" context.  The
reference counter in the persistable message is used instead, as all the async interfaces
deal directly with the message itself.

3) There are two callbacks that are invoked when a message completes: one to bind the message,
which then calls the Session's callback.  These should be collapsed to one for performance

I'd like to get some review & feedback from Alan and others before I apply this.

> c++ broker: Improvements to asynchronos completion
> --------------------------------------------------
>                 Key: QPID-2921
>                 URL: https://issues.apache.org/jira/browse/QPID-2921
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker
>    Affects Versions: 0.8
>            Reporter: Alan Conway
>            Assignee: Ken Giusti
>         Attachments: msg.patch, proposal1.diff
> ** Overview
> Asynchronous completion means that command execution is initiated in one thread
> (a client connection thread) and completed in a different thread.
> When the async store is loaded, message.transfer commands are
> completed by a store thread that does the async write.
> ** Issues with asynchronous completion code as of revision r1029686
> *** Not really asynchronous
> IncompleteMessageList::process blocks the connection thread till all
> outstanding async commands (messages) for the session are complete.
> With the new cluster, this could deadlock since it is blocking a Poller thread.
> *** Race condition for message.transfer
> Sketch of the current code:
> // Called in connection thread 
> PersistableMessage::enqueueAsync { ++counter; } 
> // Called in store thread once message is written.
> PersistableMessage::enqueueComplete { if (--counter == 0) notifyCompleted(); }
> The intent is that notify be called once per message, after the
> message has been written to each queue it was routed to.
> However of a message is routed to N queues, it's possible for
> notifyCompleted to be called up to N times. The store thread could
> call notifyCompleted for the first queue before the connection thread
> has called enqueueAsync for the second queue, and so on.
> *** No asynchronous completion for message.accept
> We do not currently delay completion of message.accept until the
> message is deleted from the async store. This could cause duplicate
> delivery if the broker crashes after completing the message but 
> before it is removed from store.
> There is code in PersistableMessage to maintain a counter for dequeues
> analogous to to the async enqueue code but this is incorrect. 
> Completion of transfer is triggered when all enqueues for a message are complete.
> Completion of accept is triggered for *each* dequeue from a queue independently.
> Furthermore a single accept can reference many messages, so it can't be associated with
a message.
> ** New requirements
> The new cluster design will need to participate in async completion, e.g.
> an accept cannot be comlpeted until the message is 
> - removed from store (if present) AND
> - replicated to the cluster (if present) as dequeued
> The new cluster also needs to asynchronously complete binding commands
> (declare, bind, delete) when they are replicated to the cluster.

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

View raw message