qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-3460) Better support for non-blocking usage in messaging API
Date Wed, 31 Aug 2011 18:02:11 GMT

    [ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094730#comment-13094730

jiraposter@reviews.apache.org commented on QPID-3460:

This is an automatically generated e-mail. To reply, visit:

Review request for Alan Conway and Darryl Pierce.


This allows multiple sessions (from multiple connections) to be managed with a single thread.
It also allows non-blocking control over senders that reach their capacity (e.g. due to flow

It does not yet cover tracking of message settlement and reconnection is still blocking.

The API changes consist of a new class, Tracker - not at all keen on that name but have yet
to come up with something I like - through which a set of sessions and/or senders can be tracked
for 'readability' or 'writability' respectively. This is somewhat asymmetric. The reason for
this choice was that in general you only care about the writability (i.e. available capacity)
of certain senders (those you have data to send out on at present), whereas generally you
care about any incoming messages. I could see this being extended to support both tracking
specific receivers and to track all senders on a session but those seem like more special
cases and not as critical at first.

The internal implementation on the 0-10 codebase leaves a lot to be desired. At present it
is certainly not the most optimal, but it has virtually no effect on users who don't use the
new class. The threading of the 0-10 client is driven by its use of the old client API underneath
it. That and the locking in the messaging API layer means that a lot of checking actually
needs to occur on application threads rather than the IO thread. Its this reason that I haven't
tried at this stage to e.g. make a file handle readable when the tracker has a next() session
available. Since it would in any case require a separate thread, little is gained at this
stage. I envisage the 1.0 implementation being able to handle that case much better, being
architected from the start with a more ideal threading.

So while this patch is still fairly rudimentary I thought it was worth sharing for some wider
comment from interested parties.

This addresses bug QPID-3460.


  /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236 
  /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236 
  /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236 
  /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236 
  /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236 
  /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION 
  /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236 
  /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION 
  /trunk/qpid/cpp/src/CMakeLists.txt 1163236 
  /trunk/qpid/cpp/src/Makefile.am 1163236 
  /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236 
  /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236 
  /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236 
  /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236 
  /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236 
  /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION 
  /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION 

Diff: https://reviews.apache.org/r/1687/diff


Minimal ad hoc testing with the new example contained in this patch.



> Better support for non-blocking usage in messaging API
> ------------------------------------------------------
>                 Key: QPID-3460
>                 URL: https://issues.apache.org/jira/browse/QPID-3460
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Client
>    Affects Versions: 0.12
>            Reporter: Gordon Sim
>            Assignee: Gordon Sim
> In particular:
> * remove the requirement for a thread-per-session when processing incoming messages
> * remove the need to either block or poll when a sender reaches its capacity
> * remove the need to poll for changes in message settlement (i.e. completion of sends
and acknowledgements)
> * allow non-blocking reconnection
> * allow integration with polling loops etc

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


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

View raw message