You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <ji...@apache.org> on 2011/08/31 18:35:09 UTC
[jira] [Created] (QPID-3460) Better support for non-blocking usage
in messaging API
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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095324#comment-13095324 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review1718
-----------------------------------------------------------
Comments on the diff.
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment3905>
Alternative name for Tracker: SessionPoller
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment3907>
Remove track(Sender). Send and receive should be symmetric and we may add more event types later.
Applications using this API will themselves be server-like and getting their own async events that trigger the need to send messages. If any session gets capacity they'll want to check if they have an event for that session. Apps that know in advance about a set of messages to send on a session won't use this API.
If there's an easy way for the user to tell which sessions are interesting, they can implement that in their own loop, no need to push that responsibility onto the Tracker.
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment3906>
I would suggest something more like sys::Poller with a single wait() function that returns an Event. That's a pretty common pattern. (seelect, poll, epoll etc)
I'd also suggest replacing track/remove
with:
void monitor(Session, incoming, outgoing)
So you can control monitoring per-session. remove becomes: monitor(session, false, false)
I think the 2 booleans probably want to be replaced by an enum or set of flags to be
more extensible.
/trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp
<https://reviews.apache.org/r/1687/#comment3908>
Why doesn't session pass this to listener?
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp
<https://reviews.apache.org/r/1687/#comment3909>
Should pass this to avoid need for map lookup by parent.
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp
<https://reviews.apache.org/r/1687/#comment3924>
why inline session.flush?
- Alan
On 2011-08-31 18:01:43, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-08-31 18:01:43)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1163236
bq. /trunk/qpid/cpp/src/Makefile.am 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098015#comment-13098015 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review1764
-----------------------------------------------------------
/trunk/qpid/cpp/include/qpid/messaging/Session.h
<https://reviews.apache.org/r/1687/#comment4005>
+1
When doing the Ruby APIs on top of Swig, one of the things that was lacking (but which wasn't used anywhere) was the ability of getting the Session name after it was created.
This will help make those APIs more consistent since we'll be able to create the Session wrapper with the name.
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment4006>
I agree that Tracker doesn't express the purpose of this code.
I disagree with calling it SessionPoller, since it's not specifically a Session-related entity.
Perhaps something like *Observer (MessageSpoolObserver)? Since the purpose, if I understand correctly, is to report whether the observed object has capacity in its incoming queue to receive messages.
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp
<https://reviews.apache.org/r/1687/#comment4007>
Small nitpick. Please wrap the boolean expression in parentheses for clarity.
- Darryl
On 2011-08-31 18:01:43, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-08-31 18:01:43)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1163236
bq. /trunk/qpid/cpp/src/Makefile.am 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098109#comment-13098109 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/
-----------------------------------------------------------
(Updated 2011-09-06 15:51:36.940385)
Review request for Alan Conway and Darryl Pierce.
Changes
-------
Added missing Tracker.cpp file
Summary
-------
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 control).
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.
https://issues.apache.org/jira/browse/QPID-3460
Diffs (updated)
-----
/trunk/qpid/cpp/examples/messaging/Makefile.am 1165228
/trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1165228
/trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
/trunk/qpid/cpp/include/qpid/messaging/Session.h 1165228
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
/trunk/qpid/cpp/src/CMakeLists.txt 1165228
/trunk/qpid/cpp/src/Makefile.am 1165228
/trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1165228
/trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1165228
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1165228
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1165228
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1165228
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
/trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
/trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1165228
/trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1165228
/trunk/qpid/cpp/src/qpid/messaging/Tracker.cpp PRE-CREATION
/trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1165228
Diff: https://reviews.apache.org/r/1687/diff
Testing
-------
Minimal ad hoc testing with the new example contained in this patch.
Thanks,
Gordon
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ 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:
https://reviews.apache.org/r/1687/
-----------------------------------------------------------
Review request for Alan Conway and Darryl Pierce.
Summary
-------
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 control).
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.
https://issues.apache.org/jira/browse/QPID-3460
Diffs
-----
/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
Testing
-------
Minimal ad hoc testing with the new example contained in this patch.
Thanks,
Gordon
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095426#comment-13095426 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp, line 449
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36893#file36893line449>
bq. >
bq. > why inline session.flush?
Its not an inlined flush, it is a sync. The reason it is done in this way is that the sync() call on the qpid::client::Session is a blocking call that waits for completion, which I did not want here. This code coould of course be moved into qpid::client::SessionBase as a new method.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 46
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line46>
bq. >
bq. > Remove track(Sender). Send and receive should be symmetric and we may add more event types later.
bq. >
bq. > Applications using this API will themselves be server-like and getting their own async events that trigger the need to send messages. If any session gets capacity they'll want to check if they have an event for that session. Apps that know in advance about a set of messages to send on a session won't use this API.
bq. >
bq. > If there's an easy way for the user to tell which sessions are interesting, they can implement that in their own loop, no need to push that responsibility onto the Tracker.
I don't think send and receive *are* symmetric. The only reason you care about send in this context is where you have messages to send but cannot do so due to capacity limits in the sender. What I think you therefore want is to be able to track when a sender is 'writable'. However in general most senders on session will be writable. So while for incoming messages the session is a good level to track, for outgoing messages sender level control is far more important in my view.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 49
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line49>
bq. >
bq. > I would suggest something more like sys::Poller with a single wait() function that returns an Event. That's a pretty common pattern. (seelect, poll, epoll etc)
bq. >
bq. > I'd also suggest replacing track/remove
bq. > with:
bq. >
bq. > void monitor(Session, incoming, outgoing)
bq. >
bq. > So you can control monitoring per-session. remove becomes: monitor(session, false, false)
bq. >
bq. > I think the 2 booleans probably want to be replaced by an enum or set of flags to be
bq. > more extensible.
bq. >
There is a wait() function as well that can be used to wait until there is an incoming message on one of the tracked sessions and/or until an outgoing message can be sent on one of the tracked senders. As above I don't think the session provides sufficient granularity for tracking ability to send without blocking; I think that needs to be done on specific senders.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp, line 628
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36890#file36890line628>
bq. >
bq. > Why doesn't session pass this to listener?
It wasn't really needed. It could do so however.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp, line 128
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36891#file36891line128>
bq. >
bq. > Should pass this to avoid need for map lookup by parent.
The parent doesn't actually use the parameter at all at present, but I could certainly modify that to pass this. The current patch is not optimised to make the tracking efficient. It was more of an exploration of the API and how it could be implemented.
- Gordon
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review1718
-----------------------------------------------------------
On 2011-08-31 18:01:43, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-08-31 18:01:43)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1163236
bq. /trunk/qpid/cpp/src/Makefile.am 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095527#comment-13095527 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 46
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line46>
bq. >
bq. > Remove track(Sender). Send and receive should be symmetric and we may add more event types later.
bq. >
bq. > Applications using this API will themselves be server-like and getting their own async events that trigger the need to send messages. If any session gets capacity they'll want to check if they have an event for that session. Apps that know in advance about a set of messages to send on a session won't use this API.
bq. >
bq. > If there's an easy way for the user to tell which sessions are interesting, they can implement that in their own loop, no need to push that responsibility onto the Tracker.
bq.
bq. Gordon Sim wrote:
bq. I don't think send and receive *are* symmetric. The only reason you care about send in this context is where you have messages to send but cannot do so due to capacity limits in the sender. What I think you therefore want is to be able to track when a sender is 'writable'. However in general most senders on session will be writable. So while for incoming messages the session is a good level to track, for outgoing messages sender level control is far more important in my view.
bq.
bq. Alan Conway wrote:
bq. We can't know in general whether there will be more sending or receiving in a given application. Applying your argument to sys::Poller, do you think we should have had a different API for reads and writes? Consider the way the broker IO works - driven by readabilty/writabiliy. Applications using this API are going to be server like applications driven by sendability/receivability. A sending application will be queuing up its own events and needs to know when they can be sent. If the senders generally do have capacity the applications queue will be empty, but whatever is driving the application may temporarily exceed capacity and the the app needs to be notified when there is capacity.
bq.
bq. I'm not arguing against a finer granularity, but it should be symmetric between read and write. If you can watch individual Senders you should also be able to watch individual receivers.
bq.
bq. The asymetric API is unclear: does track(Session) mean track all its senders and receivers or just receivers? Does remove(Session) also remove senders that were added by track(Sender)?
It's not about whether there is more sending or receiving, its what is the most common need in each case. As I mentioned in the description, I can certainly see extending this to support tracking individual receivers and also tracking all the senders for a session. However the most common cases are that you care about specific senders, but about all sessions, so thats where I started.
I agree that the asymmetry is less than ideal though.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 49
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line49>
bq. >
bq. > I would suggest something more like sys::Poller with a single wait() function that returns an Event. That's a pretty common pattern. (seelect, poll, epoll etc)
bq. >
bq. > I'd also suggest replacing track/remove
bq. > with:
bq. >
bq. > void monitor(Session, incoming, outgoing)
bq. >
bq. > So you can control monitoring per-session. remove becomes: monitor(session, false, false)
bq. >
bq. > I think the 2 booleans probably want to be replaced by an enum or set of flags to be
bq. > more extensible.
bq. >
bq.
bq. Gordon Sim wrote:
bq. There is a wait() function as well that can be used to wait until there is an incoming message on one of the tracked sessions and/or until an outgoing message can be sent on one of the tracked senders. As above I don't think the session provides sufficient granularity for tracking ability to send without blocking; I think that needs to be done on specific senders.
bq.
bq. Alan Conway wrote:
bq. In that case we need the finer granularity for receivers too.
Fair enough, but I think that is driven more by the desire for symmetry than by real world needs.
- Gordon
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review1718
-----------------------------------------------------------
On 2011-08-31 18:01:43, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-08-31 18:01:43)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1163236
bq. /trunk/qpid/cpp/src/Makefile.am 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095520#comment-13095520 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 49
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line49>
bq. >
bq. > I would suggest something more like sys::Poller with a single wait() function that returns an Event. That's a pretty common pattern. (seelect, poll, epoll etc)
bq. >
bq. > I'd also suggest replacing track/remove
bq. > with:
bq. >
bq. > void monitor(Session, incoming, outgoing)
bq. >
bq. > So you can control monitoring per-session. remove becomes: monitor(session, false, false)
bq. >
bq. > I think the 2 booleans probably want to be replaced by an enum or set of flags to be
bq. > more extensible.
bq. >
bq.
bq. Gordon Sim wrote:
bq. There is a wait() function as well that can be used to wait until there is an incoming message on one of the tracked sessions and/or until an outgoing message can be sent on one of the tracked senders. As above I don't think the session provides sufficient granularity for tracking ability to send without blocking; I think that needs to be done on specific senders.
In that case we need the finer granularity for receivers too.
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/include/qpid/messaging/Tracker.h, line 46
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36886#file36886line46>
bq. >
bq. > Remove track(Sender). Send and receive should be symmetric and we may add more event types later.
bq. >
bq. > Applications using this API will themselves be server-like and getting their own async events that trigger the need to send messages. If any session gets capacity they'll want to check if they have an event for that session. Apps that know in advance about a set of messages to send on a session won't use this API.
bq. >
bq. > If there's an easy way for the user to tell which sessions are interesting, they can implement that in their own loop, no need to push that responsibility onto the Tracker.
bq.
bq. Gordon Sim wrote:
bq. I don't think send and receive *are* symmetric. The only reason you care about send in this context is where you have messages to send but cannot do so due to capacity limits in the sender. What I think you therefore want is to be able to track when a sender is 'writable'. However in general most senders on session will be writable. So while for incoming messages the session is a good level to track, for outgoing messages sender level control is far more important in my view.
We can't know in general whether there will be more sending or receiving in a given application. Applying your argument to sys::Poller, do you think we should have had a different API for reads and writes? Consider the way the broker IO works - driven by readabilty/writabiliy. Applications using this API are going to be server like applications driven by sendability/receivability. A sending application will be queuing up its own events and needs to know when they can be sent. If the senders generally do have capacity the applications queue will be empty, but whatever is driving the application may temporarily exceed capacity and the the app needs to be notified when there is capacity.
I'm not arguing against a finer granularity, but it should be symmetric between read and write. If you can watch individual Senders you should also be able to watch individual receivers.
The asymetric API is unclear: does track(Session) mean track all its senders and receivers or just receivers? Does remove(Session) also remove senders that were added by track(Sender)?
bq. On 2011-09-01 14:44:26, Alan Conway wrote:
bq. > /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp, line 449
bq. > <https://reviews.apache.org/r/1687/diff/1/?file=36893#file36893line449>
bq. >
bq. > why inline session.flush?
bq.
bq. Gordon Sim wrote:
bq. Its not an inlined flush, it is a sync. The reason it is done in this way is that the sync() call on the qpid::client::Session is a blocking call that waits for completion, which I did not want here. This code coould of course be moved into qpid::client::SessionBase as a new method.
right
- Alan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review1718
-----------------------------------------------------------
On 2011-08-31 18:01:43, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-08-31 18:01:43)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1163236
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1163236
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1163236
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1163236
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1163236
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1163236
bq. /trunk/qpid/cpp/src/Makefile.am 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1163236
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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
[jira] [Commented] (QPID-3460) Better support for non-blocking
usage in messaging API
Posted by "jiraposter@reviews.apache.org (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112806#comment-13112806 ]
jiraposter@reviews.apache.org commented on QPID-3460:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1687/#review2025
-----------------------------------------------------------
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment4570>
To make it easier to wrap this in Ruby, please overload this API with one that takes a Duration and returns a Receiver or null.
/trunk/qpid/cpp/include/qpid/messaging/Tracker.h
<https://reviews.apache.org/r/1687/#comment4571>
Similar to nextReceiver, please add an overloaded version of nextSender that takes only a Duration and returns the Sender or null.
- Darryl
On 2011-09-06 15:51:36, Gordon Sim wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1687/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-09-06 15:51:36)
bq.
bq.
bq. Review request for Alan Conway and Darryl Pierce.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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 control).
bq.
bq. It does not yet cover tracking of message settlement and reconnection is still blocking.
bq.
bq. 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.
bq.
bq. 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.
bq.
bq. So while this patch is still fairly rudimentary I thought it was worth sharing for some wider comment from interested parties.
bq.
bq.
bq. This addresses bug QPID-3460.
bq. https://issues.apache.org/jira/browse/QPID-3460
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/examples/messaging/Makefile.am 1165228
bq. /trunk/qpid/cpp/examples/messaging/extra_dist/Makefile 1165228
bq. /trunk/qpid/cpp/examples/messaging/non_blocking.cpp PRE-CREATION
bq. /trunk/qpid/cpp/include/qpid/messaging/Session.h 1165228
bq. /trunk/qpid/cpp/include/qpid/messaging/Tracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/CMakeLists.txt 1165228
bq. /trunk/qpid/cpp/src/Makefile.am 1165228
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.h 1165228
bq. /trunk/qpid/cpp/src/qpid/client/SessionImpl.cpp 1165228
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SenderImpl.cpp 1165228
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1165228
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1165228
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.h PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionTracker.cpp PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/messaging/Session.cpp 1165228
bq. /trunk/qpid/cpp/src/qpid/messaging/SessionImpl.h 1165228
bq. /trunk/qpid/cpp/src/qpid/messaging/Tracker.cpp PRE-CREATION
bq. /trunk/qpid/cpp/src/qpid/sys/BlockingQueue.h 1165228
bq.
bq. Diff: https://reviews.apache.org/r/1687/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Minimal ad hoc testing with the new example contained in this patch.
bq.
bq.
bq. Thanks,
bq.
bq. Gordon
bq.
bq.
> 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