[jira] [Reopened] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-1000:
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1003. Resolution: Fixed This JIRA was raised for the specific issue of the error handler at the ssl transport layer, which is now resolved. PROTON-1000 covers the general leak, for which there is apparently still some fix needed. Hence resolving this and re-opening PROTON-1000. > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: qpid-proton git commit: PROTON-1036: c++: engine API for integration with external IO frameworks
I see an error, as does Travis CI (both shown below), when running make after this change. The Appveyor build is failing too (less clear if its the same reason), though the build did complete on the ASF Jenkins. After a quick google, the posts at http://stackoverflow.com/questions/14431776/c-ntohs-fails-on-higher-optimization-levels suggest the fix is to remove the "::" before ntohs, which indeed seems to get things going again for me. Any reason not to do that? Robbie Travis: [ 96%] Building CXX object examples/cpp/CMakeFiles/select_broker.dir/select_broker.cpp.o /home/travis/build/apache/qpid-proton/examples/cpp/select_broker.cpp: In member function ‘void broker::accept()’: /home/travis/build/apache/qpid-proton/examples/cpp/select_broker.cpp:139:31: error: expected id-expression before ‘(’ token Local: from /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp:20: /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp: In member function ‘void broker::accept()’: /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp:139:31: error: expected id-expression before ‘(’ token << ":" << ::ntohs(client_addr.sin_port) ^ On 2 November 2015 at 23:14, wrote: > Repository: qpid-proton > Updated Branches: > refs/heads/master 4f5e18a05 -> 193a7dd5d > > > PROTON-1036: c++: engine API for integration with external IO frameworks > > proton::engine wraps the pn transport, connection and collector objects and > provides a simple bytes-in/bytes-out interface that can be used to integrate > proton with any IO framework. > > - added proton::engine > - added proton::event_loop base class for proton::engine and > proton::container. > - extracted broker.hpp: common code for example brokers (queue and handler) > - added select_broker.cpp example > - added url::port_int() to get the integer value of a URL. > > > Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo > Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/193a7dd5 > Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/193a7dd5 > Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/193a7dd5 > > Branch: refs/heads/master > Commit: 193a7dd5d896ce62143b4a52179de067ae491abb > Parents: 4f5e18a > Author: Alan Conway > Authored: Mon Nov 2 17:56:03 2015 -0500 > Committer: Alan Conway > Committed: Mon Nov 2 18:14:08 2015 -0500 > > -- > examples/cpp/CMakeLists.txt | 6 + > examples/cpp/broker.cpp | 171 ++- > examples/cpp/broker.hpp | 213 +++ > examples/cpp/example_test.py| 3 +- > examples/cpp/select_broker.cpp | 186 > proton-c/bindings/cpp/CMakeLists.txt| 1 + > proton-c/bindings/cpp/README.md | 2 - > proton-c/bindings/cpp/docs/mainpage.md | 6 + > .../bindings/cpp/include/proton/connection.hpp | 21 +- > .../bindings/cpp/include/proton/container.hpp | 4 +- > proton-c/bindings/cpp/include/proton/engine.hpp | 155 ++ > proton-c/bindings/cpp/include/proton/event.hpp | 9 +- > .../bindings/cpp/include/proton/event_loop.hpp | 41 > proton-c/bindings/cpp/include/proton/types.hpp | 3 - > proton-c/bindings/cpp/include/proton/url.hpp| 4 + > proton-c/bindings/cpp/src/connection.cpp| 9 +- > proton-c/bindings/cpp/src/connector.cpp | 2 +- > proton-c/bindings/cpp/src/container_impl.cpp| 2 +- > proton-c/bindings/cpp/src/engine.cpp| 132 > proton-c/bindings/cpp/src/event.cpp | 9 + > proton-c/bindings/cpp/src/messaging_event.cpp | 6 +- > proton-c/bindings/cpp/src/messaging_event.hpp | 2 +- > proton-c/bindings/cpp/src/proton_event.cpp | 25 ++- > proton-c/bindings/cpp/src/proton_event.hpp | 109 +- > proton-c/bindings/cpp/src/url.cpp | 15 +- > 25 files changed, 901 insertions(+), 235 deletions(-) > -- > >
[jira] [Commented] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987198#comment-14987198 ] Otavio Rodolfo Piske commented on PROTON-1036: -- I noticed that select_broker.cpp fails to compile if one of the following GCC optimization levels is enabled: -Os, -O1, -O2, -O3. The reason for this seems to be because the function ntohs is optimized out and replaced with a macro by the compiler, therefore causing the following failure: /home/opiske/code/cpp/rh/qpid-proton/examples/cpp/select_broker.cpp: In member function ‘void broker::accept()’: /home/opiske/code/cpp/rh/qpid-proton/examples/cpp/select_broker.cpp:139:30: error: expected id-expression before ‘(’ token << ":" << ::ntohs(client_addr.sin_port) ^ examples/cpp/CMakeFiles/select_broker.dir/build.make:65: recipe for target 'examples/cpp/CMakeFiles/select_broker.dir/select_broker.cpp.o' failed make[2]: *** [examples/cpp/CMakeFiles/select_broker.dir/select_broker.cpp.o] Error 1 make[2]: Leaving directory '/home/opiske/code/cpp/rh/qpid-proton/build' CMakeFiles/Makefile2:2984: recipe for target 'examples/cpp/CMakeFiles/select_broker.dir/all' failed make[1]: *** [examples/cpp/CMakeFiles/select_broker.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987200#comment-14987200 ] ASF subversion and git services commented on PROTON-971: Commit a94e635152e5ab32c3dbe5ea87f88173d01f4ce1 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a94e635 ] PROTON-971: record the in-progress delivery on the transport link, don't send transfers for new deliveries until the existing one is completed > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10 >Reporter: Robbie Gemmell >Priority: Critical > Fix For: 0.11 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated PROTON-1036: - Attachment: ntohs-fix.patch Fix missing ::ntohs due to GCC compiler optimization > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > Attachments: ntohs-fix.patch > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-971: -- Affects Version/s: 0.11 > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-971: -- Fix Version/s: (was: 0.11) 0.12.0 > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-971. --- Resolution: Fixed Assignee: Robbie Gemmell Resolving, have updated the affects/fix-for versions to reflect current state of only being in 0.12.0, but I would like to request this fix for inclusion in 0.11.0 given its effect. > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987222#comment-14987222 ] ASF subversion and git services commented on PROTON-1036: - Commit 67549fa5bfb4e1fd5723b7f3cec20656c542c80d in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=67549fa ] PROTON-1036: remove :: to get things compiling with optimizations > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > Attachments: ntohs-fix.patch > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987224#comment-14987224 ] Robbie Gemmell commented on PROTON-1036: I had just posted about the same thing on the mailing lists, so I have jsut pushed the change, if there is an alternative change then someone with more of a clue can make it :) > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > Attachments: ntohs-fix.patch > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: qpid-proton git commit: PROTON-1036: c++: engine API for integration with external IO frameworks
Otavio suggested the same change on the JIRA so I just went ahead and made it. If there is a better change then someone with more of a clue can still make it ;) Robbie On 3 November 2015 at 12:43, Robbie Gemmell wrote: > I see an error, as does Travis CI (both shown below), when running > make after this change. The Appveyor build is failing too (less clear > if its the same reason), though the build did complete on the ASF > Jenkins. After a quick google, the posts at > http://stackoverflow.com/questions/14431776/c-ntohs-fails-on-higher-optimization-levels > suggest the fix is to remove the "::" before ntohs, which indeed seems > to get things going again for me. Any reason not to do that? > > Robbie > > > Travis: > [ 96%] Building CXX object > examples/cpp/CMakeFiles/select_broker.dir/select_broker.cpp.o > /home/travis/build/apache/qpid-proton/examples/cpp/select_broker.cpp: > In member function ‘void broker::accept()’: > /home/travis/build/apache/qpid-proton/examples/cpp/select_broker.cpp:139:31: > error: expected id-expression before ‘(’ token > > Local: > from > /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp:20: > /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp: In > member function ‘void broker::accept()’: > /home/gemmellr/workspace/proton/examples/cpp/select_broker.cpp:139:31: > error: expected id-expression before ‘(’ token ><< ":" << ::ntohs(client_addr.sin_port) >^ > > On 2 November 2015 at 23:14, wrote: >> Repository: qpid-proton >> Updated Branches: >> refs/heads/master 4f5e18a05 -> 193a7dd5d >> >> >> PROTON-1036: c++: engine API for integration with external IO frameworks >> >> proton::engine wraps the pn transport, connection and collector objects and >> provides a simple bytes-in/bytes-out interface that can be used to integrate >> proton with any IO framework. >> >> - added proton::engine >> - added proton::event_loop base class for proton::engine and >> proton::container. >> - extracted broker.hpp: common code for example brokers (queue and handler) >> - added select_broker.cpp example >> - added url::port_int() to get the integer value of a URL. >> >> >> Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo >> Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/193a7dd5 >> Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/193a7dd5 >> Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/193a7dd5 >> >> Branch: refs/heads/master >> Commit: 193a7dd5d896ce62143b4a52179de067ae491abb >> Parents: 4f5e18a >> Author: Alan Conway >> Authored: Mon Nov 2 17:56:03 2015 -0500 >> Committer: Alan Conway >> Committed: Mon Nov 2 18:14:08 2015 -0500 >> >> -- >> examples/cpp/CMakeLists.txt | 6 + >> examples/cpp/broker.cpp | 171 ++- >> examples/cpp/broker.hpp | 213 +++ >> examples/cpp/example_test.py| 3 +- >> examples/cpp/select_broker.cpp | 186 >> proton-c/bindings/cpp/CMakeLists.txt| 1 + >> proton-c/bindings/cpp/README.md | 2 - >> proton-c/bindings/cpp/docs/mainpage.md | 6 + >> .../bindings/cpp/include/proton/connection.hpp | 21 +- >> .../bindings/cpp/include/proton/container.hpp | 4 +- >> proton-c/bindings/cpp/include/proton/engine.hpp | 155 ++ >> proton-c/bindings/cpp/include/proton/event.hpp | 9 +- >> .../bindings/cpp/include/proton/event_loop.hpp | 41 >> proton-c/bindings/cpp/include/proton/types.hpp | 3 - >> proton-c/bindings/cpp/include/proton/url.hpp| 4 + >> proton-c/bindings/cpp/src/connection.cpp| 9 +- >> proton-c/bindings/cpp/src/connector.cpp | 2 +- >> proton-c/bindings/cpp/src/container_impl.cpp| 2 +- >> proton-c/bindings/cpp/src/engine.cpp| 132 >> proton-c/bindings/cpp/src/event.cpp | 9 + >> proton-c/bindings/cpp/src/messaging_event.cpp | 6 +- >> proton-c/bindings/cpp/src/messaging_event.hpp | 2 +- >> proton-c/bindings/cpp/src/proton_event.cpp | 25 ++- >> proton-c/bindings/cpp/src/proton_event.hpp | 109 +- >> proton-c/bindings/cpp/src/url.cpp | 15 +- >> 25 files changed, 901 insertions(+), 235 deletions(-) >> -- >> >> > >
Re: Proton 0.11.0 release update - Beta is available
On 28 October 2015 at 10:49, Justin Ross wrote: > Hi, everyone. The beta is now available from the following URL: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-beta/ > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapacheqpid-1047 > > Test output from my machine, Fedora 22 x86-64: > > http://people.apache.org/~jross/qpid-releases/quirk-proton-0.11.0-beta.log > > Take notice! We are on a compressed schedule. Alpha was one week ago, and > RC is only one week away. We very much need testing and feedback on the > beta release. > > With the beta, we've branched for release, and release-branch commits > require approval. The release page[1] describes the procedure and criteria. > > Thanks! > Justin > > --- > [1] Proton 0.11.0 release page: > https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.11.0 I would like to request https://issues.apache.org/jira/browse/PROTON-971 for inclusion, a fix for possible corruption of the payload for buffered multi-frame deliveries being sent on the same link. Robbie
[jira] [Commented] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987296#comment-14987296 ] Alan Conway commented on PROTON-1036: - Thanks, that is the right fix. > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > Attachments: ntohs-fix.patch > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-949) proton doesn't build with ccache swig
[ https://issues.apache.org/jira/browse/PROTON-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-949: -- Assignee: Alan Conway > proton doesn't build with ccache swig > - > > Key: PROTON-949 > URL: https://issues.apache.org/jira/browse/PROTON-949 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish >Assignee: Alan Conway > > Thanks to aconway for finding this and saving me a day of madness and horror. > On freshly-downloaded proton tree, if I use this swig: >/usr/lib64/ccache/swig > the build fails this way: > qpid-proton/build/proton-c/bindings/python/cprotonPYTHON_wrap.c:4993:25: > error: 'PN_HANDLE' undeclared (first use in this function) > PNI_PYTRACER = *((PN_HANDLE *)(argp)); > -- > but if I delete that swig executable, and use the one in /bin/swig , > then everything works. > yikes. > aconway believes the bug is in ccache-swig, not in proton, but I want to put > this here in case this bites someone else in Proton Land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987428#comment-14987428 ] Timothy Bish commented on PROTON-971: - Reviewed the changes, fix seems valid. > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-971: --- Fix Version/s: 0.11 > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.11, 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-971: --- Fix Version/s: (was: 0.11) > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987454#comment-14987454 ] Justin Ross commented on PROTON-971: Reviewed by Tim. Approved for 0.11.0. > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987494#comment-14987494 ] ASF subversion and git services commented on PROTON-971: Commit 3c527d2f09977f629fc34c5285e847949ceacb99 in qpid-proton's branch refs/heads/0.11.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3c527d2 ] PROTON-971: record the in-progress delivery on the transport link, don't send transfers for new deliveries until the existing one is completed (cherry picked from commit a94e635152e5ab32c3dbe5ea87f88173d01f4ce1) > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1034) [Go binding] Windows build fails if Go language is installed but no gcc tool kit
[ https://issues.apache.org/jira/browse/PROTON-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987501#comment-14987501 ] ASF subversion and git services commented on PROTON-1034: - Commit aa7b4ac26c9fb11f1f9ae18795da835b154da4ec in qpid-proton's branch refs/heads/0.11.x from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=aa7b4ac ] PROTON-1034: Go binding on Windows defaults to Off > [Go binding] Windows build fails if Go language is installed but no gcc tool > kit > > > Key: PROTON-1034 > URL: https://issues.apache.org/jira/browse/PROTON-1034 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: 0.11 > Environment: Windows with Go but without CYGWIN gcc. >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > Go builds detect the presence of the Go executable and build based on that. > On Windows the build also requires gcc/ld which are part of a separate tool > kit such MINGW or CYGWIN. Even then there are issues with > * the debug postfix 'd' character on library names > * 32-bit/64-bit library detection > The proton-c builds should still work even if Go is installed. This issue > tracks solving the build problem by defaulting the Go binding to OFF on > windows. Users with or without Go installed will still get a good proton > build but with no Go binding. A developer can issue -DBUILD_GO=Yes to force > the build while he works out the gcc interface issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987509#comment-14987509 ] Robbie Gemmell commented on PROTON-971: --- Now merged to 0.11.x branch for inclusion in 0.11.0 > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.11 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-971: -- Affects Version/s: (was: 0.11) > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.11 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-971: -- Fix Version/s: (was: 0.12.0) 0.11 > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.11 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-949) proton doesn't build with ccache swig
[ https://issues.apache.org/jira/browse/PROTON-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987645#comment-14987645 ] ASF subversion and git services commented on PROTON-949: Commit 2a1e1e7a03d6e23dea83ade03446d983026d4476 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2a1e1e7 ] PROTON-949: fix proton build with ccache swig Moved macro calls and preprocessor directives out of %inline sections, seems to fix the problem. NOTE: According to ccache-swig man page: "Known problems are using preprocessor directives within %inline blocks and the use of ’#pragma SWIG’." This includes using any macros in an %inline section. > proton doesn't build with ccache swig > - > > Key: PROTON-949 > URL: https://issues.apache.org/jira/browse/PROTON-949 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish >Assignee: Alan Conway > > Thanks to aconway for finding this and saving me a day of madness and horror. > On freshly-downloaded proton tree, if I use this swig: >/usr/lib64/ccache/swig > the build fails this way: > qpid-proton/build/proton-c/bindings/python/cprotonPYTHON_wrap.c:4993:25: > error: 'PN_HANDLE' undeclared (first use in this function) > PNI_PYTRACER = *((PN_HANDLE *)(argp)); > -- > but if I delete that swig executable, and use the one in /bin/swig , > then everything works. > yikes. > aconway believes the bug is in ccache-swig, not in proton, but I want to put > this here in case this bites someone else in Proton Land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1036) c++: engine API for integration with external IO frameworks
[ https://issues.apache.org/jira/browse/PROTON-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987855#comment-14987855 ] ASF subversion and git services commented on PROTON-1036: - Commit a8f8a0ea697b46d67aebc6ad44cc6c1fdbd11694 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a8f8a0e ] PROTON-1036: c++: disable select test on windows Test is not portable, disabling till fixed. > c++: engine API for integration with external IO frameworks > --- > > Key: PROTON-1036 > URL: https://issues.apache.org/jira/browse/PROTON-1036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.11 > > Attachments: ntohs-fix.patch > > > Provide a simple bytes-in/bytes-out per-connection engine to allow simple > intergration of proton with external IO frameworks, where the goal is to have > proton do *only* the AMQP decoding/encodiing/event handling and let the > external framework take care of everything else: IO, timers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
web sockets and proton-c
Anyone have any commentary on using web sockets with proton-c? Are there any good experiences with open source libraries? Any pointers in integrating proton-c with a web sockets client library? Thank you, Tony Ercolano
[jira] [Resolved] (PROTON-1034) [Go binding] Windows build fails if Go language is installed but no gcc tool kit
[ https://issues.apache.org/jira/browse/PROTON-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-1034. - Resolution: Fixed Fix Version/s: 0.11 Fixed at commit 288070d > [Go binding] Windows build fails if Go language is installed but no gcc tool > kit > > > Key: PROTON-1034 > URL: https://issues.apache.org/jira/browse/PROTON-1034 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: 0.11 > Environment: Windows with Go but without CYGWIN gcc. >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.11 > > > Go builds detect the presence of the Go executable and build based on that. > On Windows the build also requires gcc/ld which are part of a separate tool > kit such MINGW or CYGWIN. Even then there are issues with > * the debug postfix 'd' character on library names > * 32-bit/64-bit library detection > The proton-c builds should still work even if Go is installed. This issue > tracks solving the build problem by defaulting the Go binding to OFF on > windows. Users with or without Go installed will still get a good proton > build but with no Go binding. A developer can issue -DBUILD_GO=Yes to force > the build while he works out the gcc interface issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1033) Update the revision of the libqpid-proton library to 4
[ https://issues.apache.org/jira/browse/PROTON-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987960#comment-14987960 ] ASF subversion and git services commented on PROTON-1033: - Commit c007867e9a972c3aa84137b39f44889499620f75 in qpid-proton's branch refs/heads/0.11.x from [~justi9] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c007867 ] PROTON-1033: Bump the so version to 4 > Update the revision of the libqpid-proton library to 4 > -- > > Key: PROTON-1033 > URL: https://issues.apache.org/jira/browse/PROTON-1033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Justin Ross >Priority: Blocker > Fix For: 0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1033) Update the revision of the libqpid-proton library to 4
[ https://issues.apache.org/jira/browse/PROTON-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1033. - Resolution: Fixed > Update the revision of the libqpid-proton library to 4 > -- > > Key: PROTON-1033 > URL: https://issues.apache.org/jira/browse/PROTON-1033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Justin Ross >Priority: Blocker > Fix For: 0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1033) Update the revision of the libqpid-proton library to 4
[ https://issues.apache.org/jira/browse/PROTON-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987976#comment-14987976 ] ASF subversion and git services commented on PROTON-1033: - Commit eb4e0473e33377b4c2fa784957a98b18ff65509a in qpid-proton's branch refs/heads/master from [~justi9] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=eb4e047 ] PROTON-1033: Bump the master so version to 5 in preparation for the next release > Update the revision of the libqpid-proton library to 4 > -- > > Key: PROTON-1033 > URL: https://issues.apache.org/jira/browse/PROTON-1033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Justin Ross >Priority: Blocker > Fix For: 0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1022) 0.11.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14988429#comment-14988429 ] ASF subversion and git services commented on PROTON-1022: - Commit e2ca91169212b4e7aca5010a248f52c82d3a3491 in qpid-proton's branch refs/heads/0.11.x from [~justi9] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e2ca911 ] PROTON-1022: Update versions for 0.11.0-rc > 0.11.0 release tasks > > > Key: PROTON-1022 > URL: https://issues.apache.org/jira/browse/PROTON-1022 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Proton 0.11.0 release update - The release candidate
Hi, all. The RC is now available here: https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1048/ I will be away from my keyboard for the remainder of this week. On Monday, the 9th, I will start the release vote if no blockers have been discovered in the interim. Thank you very much to everyone who tested the alpha and beta. If you've not yet taken a look, please test the RC and report your results. Thanks! Justin --- Proton 0.11.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.11.0
