[jira] [Created] (PROTON-26) Engine api naming proposal
Justin Ross created PROTON-26: - Summary: Engine api naming proposal Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Justin Ross -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-26) Engine api naming proposal
[ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-26: -- Component/s: proton-j Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-26) Engine api naming proposal
[ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-26: -- Attachment: proton-engine-naming-proposal-3.pdf Attached an updated proposal with Rafi's comments and recent changes factored in. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-26) Engine api naming proposal
[ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531571#comment-13531571 ] Justin Ross commented on PROTON-26: --- That's really not the case. Rejecting it is fine, but it's mostly gone undiscussed. That's partly my fault. A post to the mailing list with highlights suitable for inline comments is incoming. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Assignee: Rafael H. Schloming Labels: api Fix For: 0.2 Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-366) Add a protocol dump utility for java
Justin Ross created PROTON-366: -- Summary: Add a protocol dump utility for java Key: PROTON-366 URL: https://issues.apache.org/jira/browse/PROTON-366 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Justin Ross Priority: Minor This bug was originally under the QPID jira instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-366) Add a protocol dump utility for java
[ https://issues.apache.org/jira/browse/PROTON-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-366: --- Attachment: QPID-4106.patch From Hiram: Attaching patch which contains the protocol dump utility and also some example protocol dumps taken from some SwitfMQ AMQP sessions. Add a protocol dump utility for java Key: PROTON-366 URL: https://issues.apache.org/jira/browse/PROTON-366 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Justin Ross Priority: Minor Attachments: QPID-4106.patch This bug was originally under the QPID jira instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-399) 'Make install' doesn't install ruby qpid_messaging
Justin Ross created PROTON-399: -- Summary: 'Make install' doesn't install ruby qpid_messaging Key: PROTON-399 URL: https://issues.apache.org/jira/browse/PROTON-399 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Fedora 16 x86-64 Reporter: Justin Ross -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-400) 'Make install' doesn't install perl qpid_proton
Justin Ross created PROTON-400: -- Summary: 'Make install' doesn't install perl qpid_proton Key: PROTON-400 URL: https://issues.apache.org/jira/browse/PROTON-400 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Fedora 16 x86-64 Reporter: Justin Ross -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-399) 'Make install' doesn't install ruby qpid_proton
[ https://issues.apache.org/jira/browse/PROTON-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734723#comment-13734723 ] Justin Ross commented on PROTON-399: That's not the path I would choose. For one, the proton README strongly suggests that it is in the business of buildiing and installing the bindings. Indeed, it already does install the complete python binding. For two, I don't think lots of little source distributions is much benefit. At any rate, the state we're in now, where one can reasonably expect from the documentation that this will work (and by luck of the draw does or doesn't language for your language), is no good. 'Make install' doesn't install ruby qpid_proton --- Key: PROTON-399 URL: https://issues.apache.org/jira/browse/PROTON-399 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Fedora 16 x86-64 Reporter: Justin Ross -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-400) 'Make install' doesn't install perl qpid_proton
[ https://issues.apache.org/jira/browse/PROTON-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13735129#comment-13735129 ] Justin Ross commented on PROTON-400: Thanks, Darryl! I'll give it a try. 'Make install' doesn't install perl qpid_proton --- Key: PROTON-400 URL: https://issues.apache.org/jira/browse/PROTON-400 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Fedora 16 x86-64 Reporter: Justin Ross Assignee: Darryl L. Pierce Fix For: 0.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-462) Documentation: Add doxygen overview file for Proton C API
[ https://issues.apache.org/jira/browse/PROTON-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13826921#comment-13826921 ] Justin Ross commented on PROTON-462: For reference, the C++ doxygen overview: https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/docs/api/doxygen_mainpage.h Documentation: Add doxygen overview file for Proton C API - Key: PROTON-462 URL: https://issues.apache.org/jira/browse/PROTON-462 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Fix For: 0.6 If possible, have the web page link to the *public header files* as the start page - that's were the meat of the API documentation exists. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-521) Replace proton-project with proton in maven related build files
[ https://issues.apache.org/jira/browse/PROTON-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13908184#comment-13908184 ] Justin Ross commented on PROTON-521: I asked Irina to raise this request. The request is withdrawn. Replace proton-project with proton in maven related build files --- Key: PROTON-521 URL: https://issues.apache.org/jira/browse/PROTON-521 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Irina Boverman Priority: Trivial Fix For: 0.7 Attachments: replace-proton-project.txt This change makes it easier to build downstream products. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-521) Replace proton-project with proton in maven related build files
[ https://issues.apache.org/jira/browse/PROTON-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911908#comment-13911908 ] Justin Ross commented on PROTON-521: The benefit is simply to avoid an extra word users will likely forget and then need to look up. To most people this thing is proton, and -project is an arbitrary extra; other components don't add -project. The artifactId gets reflected into package names and is therefore part of the user experience. I appreciate what you're saying about all the change that's been going on, and about the collision with a previous iteration of things. This is certainly not a high priority. Replace proton-project with proton in maven related build files --- Key: PROTON-521 URL: https://issues.apache.org/jira/browse/PROTON-521 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Irina Boverman Priority: Trivial Fix For: 0.7 Attachments: replace-proton-project.txt This change makes it easier to build downstream products. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-542) Message.properties should default to an empty dictionary
Justin Ross created PROTON-542: -- Summary: Message.properties should default to an empty dictionary Key: PROTON-542 URL: https://issues.apache.org/jira/browse/PROTON-542 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.7 Reporter: Justin Ross Message.properties should default to an empty dictionary, not null. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-544) Subscriptions have no documentation
Justin Ross created PROTON-544: -- Summary: Subscriptions have no documentation Key: PROTON-544 URL: https://issues.apache.org/jira/browse/PROTON-544 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.7 Reporter: Justin Ross For instance, you really want to know that when you do this: sub = msgr.subscribe(amqp://0.0.0.0/#) You have sub.address, so you can do this: msg = Message() msg.reply_to = sub.address The API doc for Messenger.subscribe says nothing about its return value, and Subscription is not among the classes in the generated API doc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-549) Perl and Python bindings produces warning on Fedora
Justin Ross created PROTON-549: -- Summary: Perl and Python bindings produces warning on Fedora Key: PROTON-549 URL: https://issues.apache.org/jira/browse/PROTON-549 Project: Qpid Proton Issue Type: Bug Components: perl-binding, python-binding Affects Versions: 0.7 Environment: Fedora 19, x86-64 Reporter: Justin Ross Priority: Minor [...] Linking C shared module _cproton.so [ 69%] Built target _cproton [ 71%] Swig source /home/jross/code/qpid-proton/proton-c/include/proton/types.h:56: Warning 801: Wrong class name (corrected to `Pn_decimal128_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:56: Warning 801: Wrong class name (corrected to `Pn_decimal128_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:59: Warning 801: Wrong class name (corrected to `Pn_uuid_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:59: Warning 801: Wrong class name (corrected to `Pn_uuid_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:63: Warning 801: Wrong class name (corrected to `Pn_bytes_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:63: Warning 801: Wrong class name (corrected to `Pn_bytes_t') /home/jross/code/qpid-proton/proton-c/include/proton/object.h:50: Warning 801: Wrong class name (corrected to `Pn_class_t') /home/jross/code/qpid-proton/proton-c/include/proton/object.h:50: Warning 801: Wrong class name (corrected to `Pn_class_t') /home/jross/code/qpid-proton/proton-c/include/proton/delivery.h:50: Warning 801: Wrong class name (corrected to `Pn_delivery_tag_t') /home/jross/code/qpid-proton/proton-c/include/proton/delivery.h:50: Warning 801: Wrong class name (corrected to `Pn_delivery_tag_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:71: Warning 801: Wrong class name (corrected to `Pn_atom_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:71: Warning 801: Wrong class name (corrected to `Pn_atom_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:92: Warning 801: Wrong class name (corrected to `Pn_atom_t_u') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:92: Warning 801: Wrong class name (corrected to `Pn_atom_t_u') Scanning dependencies of target cproton-ruby [ 73%] Building C object proton-c/bindings/ruby/CMakeFiles/cproton-ruby.dir/rubyRUBY_wrap.c.o Linking C shared module cproton.so [ 73%] Built target cproton-ruby [ 75%] Swig source Scanning dependencies of target cproton [ 76%] Building C object proton-c/bindings/php/CMakeFiles/cproton.dir/phpPHP_wrap.c.o Linking C shared module cproton.so [ 76%] Built target cproton [ 78%] Swig source /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:25: Warning 302: Identifier 'uint32_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:16: Warning 302: previous definition of 'uint32_t'. /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:26: Warning 302: Identifier 'int32_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:18: Warning 302: previous definition of 'int32_t'. /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:27: Warning 302: Identifier 'uint64_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:17: Warning 302: previous definition of 'uint64_t'. Scanning dependencies of target cproton_perl [ 80%] Building C object proton-c/bindings/perl/CMakeFiles/cproton_perl.dir/perlPERL_wrap.c.o /home/jross/code/qpid-proton/build/proton-c/bindings/perl/perlPERL_wrap.c: In function '_wrap_pn_data_put_uuid': /home/jross/code/qpid-proton/build/proton-c/bindings/perl/perlPERL_wrap.c:22188:19: warning: initialization from incompatible pointer type [enabled by default] AV* tmpav = SvRV(ST(1)); ^ Linking C shared module libcproton_perl.so [ 80%] Built target cproton_perl [...] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-549) Perl and Python bindings produce warnings on Fedora
[ https://issues.apache.org/jira/browse/PROTON-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-549: --- Summary: Perl and Python bindings produce warnings on Fedora (was: Perl and Python bindings produces warning on Fedora) Perl and Python bindings produce warnings on Fedora --- Key: PROTON-549 URL: https://issues.apache.org/jira/browse/PROTON-549 Project: Qpid Proton Issue Type: Bug Components: perl-binding, python-binding Affects Versions: 0.7 Environment: Fedora 19, x86-64 Reporter: Justin Ross Priority: Minor [...] Linking C shared module _cproton.so [ 69%] Built target _cproton [ 71%] Swig source /home/jross/code/qpid-proton/proton-c/include/proton/types.h:56: Warning 801: Wrong class name (corrected to `Pn_decimal128_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:56: Warning 801: Wrong class name (corrected to `Pn_decimal128_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:59: Warning 801: Wrong class name (corrected to `Pn_uuid_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:59: Warning 801: Wrong class name (corrected to `Pn_uuid_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:63: Warning 801: Wrong class name (corrected to `Pn_bytes_t') /home/jross/code/qpid-proton/proton-c/include/proton/types.h:63: Warning 801: Wrong class name (corrected to `Pn_bytes_t') /home/jross/code/qpid-proton/proton-c/include/proton/object.h:50: Warning 801: Wrong class name (corrected to `Pn_class_t') /home/jross/code/qpid-proton/proton-c/include/proton/object.h:50: Warning 801: Wrong class name (corrected to `Pn_class_t') /home/jross/code/qpid-proton/proton-c/include/proton/delivery.h:50: Warning 801: Wrong class name (corrected to `Pn_delivery_tag_t') /home/jross/code/qpid-proton/proton-c/include/proton/delivery.h:50: Warning 801: Wrong class name (corrected to `Pn_delivery_tag_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:71: Warning 801: Wrong class name (corrected to `Pn_atom_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:71: Warning 801: Wrong class name (corrected to `Pn_atom_t') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:92: Warning 801: Wrong class name (corrected to `Pn_atom_t_u') /home/jross/code/qpid-proton/proton-c/include/proton/codec.h:92: Warning 801: Wrong class name (corrected to `Pn_atom_t_u') Scanning dependencies of target cproton-ruby [ 73%] Building C object proton-c/bindings/ruby/CMakeFiles/cproton-ruby.dir/rubyRUBY_wrap.c.o Linking C shared module cproton.so [ 73%] Built target cproton-ruby [ 75%] Swig source Scanning dependencies of target cproton [ 76%] Building C object proton-c/bindings/php/CMakeFiles/cproton.dir/phpPHP_wrap.c.o Linking C shared module cproton.so [ 76%] Built target cproton [ 78%] Swig source /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:25: Warning 302: Identifier 'uint32_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:16: Warning 302: previous definition of 'uint32_t'. /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:26: Warning 302: Identifier 'int32_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:18: Warning 302: previous definition of 'int32_t'. /home/jross/code/qpid-proton/proton-c/include/proton/cproton.i:27: Warning 302: Identifier 'uint64_t' redefined (ignored), /home/jross/code/qpid-proton/proton-c/bindings/perl/perl.i:17: Warning 302: previous definition of 'uint64_t'. Scanning dependencies of target cproton_perl [ 80%] Building C object proton-c/bindings/perl/CMakeFiles/cproton_perl.dir/perlPERL_wrap.c.o /home/jross/code/qpid-proton/build/proton-c/bindings/perl/perlPERL_wrap.c: In function '_wrap_pn_data_put_uuid': /home/jross/code/qpid-proton/build/proton-c/bindings/perl/perlPERL_wrap.c:22188:19: warning: initialization from incompatible pointer type [enabled by default] AV* tmpav = SvRV(ST(1)); ^ Linking C shared module libcproton_perl.so [ 80%] Built target cproton_perl [...] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-550) Ruby tests fail if dependencies are missing
Justin Ross created PROTON-550: -- Summary: Ruby tests fail if dependencies are missing Key: PROTON-550 URL: https://issues.apache.org/jira/browse/PROTON-550 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.7 Environment: Fedora 19, x86-64 Reporter: Justin Ross The ruby tests fail (that is, they do not opt out) if I don't have rspec and simplecov installed. On Fedora, I had to install rubygem-rspec and rubygem-simplecov. These deps, if missing, should produce warnings in the initial cmake output. If missing, the tests should be skipped. Finally, rspec and simplecov should be listed in the README with minitest. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-540) [proton-c] Messenger segfault when shutting down
[ https://issues.apache.org/jira/browse/PROTON-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13955137#comment-13955137 ] Justin Ross commented on PROTON-540: I'm seeing this as well (every time I run the tests, so far) on my system (Fedora 19, x86-64). [proton-c] Messenger segfault when shutting down Key: PROTON-540 URL: https://issues.apache.org/jira/browse/PROTON-540 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.7 The 'star_topology' Messenger test are throwing the occasional seg-fault. Here's a valgrind backtrace: proton_tests.soak.MessengerTests.test_star_topology_valgrind .. fail Error during test: Traceback (most recent call last): File ./tests/python/proton-test, line 352, in run phase() File /home/kgiusti/work/proton/0.7/qpid-proton-0.7/tests/python/proton_tests/soak.py, line 348, in test_star_topology_valgrind self._do_star_topology_test( MessengerReceiverValgrind, MessengerSenderValgrind ) File /home/kgiusti/work/proton/0.7/qpid-proton-0.7/tests/python/proton_tests/soak.py, line 280, in _do_star_topology_test self._do_test(iterations) File /home/kgiusti/work/proton/0.7/qpid-proton-0.7/tests/python/proton_tests/soak.py, line 112, in _do_test R.stderr())) AssertionError: Command '['/usr/bin/valgrind', '--error-exitcode=1', '--quiet', '--trace-children=yes', '--leak-check=full', '--suppressions=/home/kgiusti/work/proton/0.7/qpid-proton-0.7/tests/python/proton_tests/valgrind.supp', 'msgr-recv', '-X', 'READY', '-a', 'amqp://~0.0.0.0:62305,amqp://~0.0.0.0:57030,amqp://~0.0.0.0:63714', '-c', '1530', '-t', '60', '-R']' failed status=1: '==16855== Invalid read of size 8 ==16855==at 0x4C258CE: pn_compare (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C25959: pn_equals (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C25D79: pn_list_index (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C25DE8: pn_list_remove (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C445FE: pn_listener_ctx_free (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C442D1: pni_listener_finalize (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C4AC22: pn_selectable_finalize (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C25745: pn_finalize (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C256BE: pn_decref (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C257E0: pn_free (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C4B126: pn_selectable_free (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C46AED: pni_wait (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855== Address 0x4ea6bb0 is 16 bytes before a block of size 56 alloc'd ==16855==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16855==by 0x4C443ED: pn_listener_ctx (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4C47928: pn_messenger_subscribe (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/proton-c/libqpid-proton.so.2.0.0) ==16855==by 0x4021CE: main (in /home/kgiusti/work/proton/0.7/qpid-proton-0.7/build/tests/tools/apps/c/msgr-recv) ==16855== The problem is that the pn_listener_ctx is allocated using malloc: pn_listener_ctx_t *ctx = (pn_listener_ctx_t *) malloc(sizeof(pn_listener_ctx_t)); ctx-messenger = messenger; but it is stored on a pn_list (messenger-listeners) - which assumes it is derived from an object type. When messenger tries to clean up a listener, the pn_list attempts to access the non-existing clazz header. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-561) Using the java broker, messenger apparently doesn't propagate error back from broker to messenger
Justin Ross created PROTON-561:
--
Summary: Using the java broker, messenger apparently doesn't
propagate error back from broker to messenger
Key: PROTON-561
URL: https://issues.apache.org/jira/browse/PROTON-561
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Justin Ross
(The java broker logging for AMQP 1.0 is minimal; I'll mention that in another
jira.)
The test program below simply hangs. It didn't seem to want to time out,
either.
{noformat}
from proton import Message, Messenger
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5672/test
msg.body = test
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
By contrast, the same operation rendered in the qpid_messaging API produces the
expected error:
{noformat}
import sys
# You will need to build the swig python binding and point at it
sys.path.append(/home/jross/code/qpid/cpp/build/bindings/qpid/python)
from qpid_messaging import Connection
conn = Connection(0.0.0.0:5672, protocol=amqp1.0)
conn.open()
try:
session = conn.session()
sender = session.sender(test)
message = Message(test)
sender.send(message)
finally:
conn.close()
{noformat}
Error:
{noformat}
Traceback (most recent call last):
File /home/jross/test2.py, line 13, in module
sender = session.sender(test)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py, line
560, in sender
s = self._sender(target)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py, line
532, in _sender
def _sender(self, *args): return _qpid_messaging.Session__sender(self,
*args)
_qpid_messaging.NotFound: No such target : test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-561) Using the java broker, messenger apparently doesn't propagate error back from broker to messenger
[
https://issues.apache.org/jira/browse/PROTON-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966819#comment-13966819
]
Justin Ross commented on PROTON-561:
I get the same result with trunk.
Using the java broker, messenger apparently doesn't propagate error back from
broker to messenger
-
Key: PROTON-561
URL: https://issues.apache.org/jira/browse/PROTON-561
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6, 0.7
Reporter: Justin Ross
(The java broker logging for AMQP 1.0 is minimal; I'll mention that in
another jira.)
The test program below simply hangs. It didn't seem to want to time out,
either.
{noformat}
from proton import Message, Messenger
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5672/test
msg.body = test
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
By contrast, the same operation rendered in the qpid_messaging API produces
the expected error:
{noformat}
import sys
# You will need to build the swig python binding and point at it
sys.path.append(/home/jross/code/qpid/cpp/build/bindings/qpid/python)
from qpid_messaging import Connection
conn = Connection(0.0.0.0:5672, protocol=amqp1.0)
conn.open()
try:
session = conn.session()
sender = session.sender(test)
message = Message(test)
sender.send(message)
finally:
conn.close()
{noformat}
Error:
{noformat}
Traceback (most recent call last):
File /home/jross/test2.py, line 13, in module
sender = session.sender(test)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 560, in sender
s = self._sender(target)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 532, in _sender
def _sender(self, *args): return _qpid_messaging.Session__sender(self,
*args)
_qpid_messaging.NotFound: No such target : test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-561) Using the java broker, messenger apparently doesn't propagate error back from broker to messenger
[
https://issues.apache.org/jira/browse/PROTON-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-561:
---
Affects Version/s: 0.7
Using the java broker, messenger apparently doesn't propagate error back from
broker to messenger
-
Key: PROTON-561
URL: https://issues.apache.org/jira/browse/PROTON-561
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6, 0.7
Reporter: Justin Ross
(The java broker logging for AMQP 1.0 is minimal; I'll mention that in
another jira.)
The test program below simply hangs. It didn't seem to want to time out,
either.
{noformat}
from proton import Message, Messenger
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5672/test
msg.body = test
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
By contrast, the same operation rendered in the qpid_messaging API produces
the expected error:
{noformat}
import sys
# You will need to build the swig python binding and point at it
sys.path.append(/home/jross/code/qpid/cpp/build/bindings/qpid/python)
from qpid_messaging import Connection
conn = Connection(0.0.0.0:5672, protocol=amqp1.0)
conn.open()
try:
session = conn.session()
sender = session.sender(test)
message = Message(test)
sender.send(message)
finally:
conn.close()
{noformat}
Error:
{noformat}
Traceback (most recent call last):
File /home/jross/test2.py, line 13, in module
sender = session.sender(test)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 560, in sender
s = self._sender(target)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 532, in _sender
def _sender(self, *args): return _qpid_messaging.Session__sender(self,
*args)
_qpid_messaging.NotFound: No such target : test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-561) Using the java broker, messenger apparently doesn't propagate error back from broker to messenger
[
https://issues.apache.org/jira/browse/PROTON-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966882#comment-13966882
]
Justin Ross commented on PROTON-561:
Sure!
{noformat}
jross@localhost bailey$ LD_LIBRARY_PATH=/tmp/tmp.mXaVrrHF8a/lib64
PYTHONPATH=/tmp/tmp.mXaVrrHF8a/lib64/proton/bindings/python/ PN_TRACE_FRM=1
python ~/test.py
[0x221be30]: - SASL
[0x221be30]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b]
[0x221be30]: - SASL
[0x221be30]:0 - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :DIGEST-MD5, :PLAIN]]
[0x221be30]:0 - @sasl-outcome(68) [code=0]
[0x221be30]: - AMQP
[0x221be30]:0 - @open(16)
[container-id=2c45594d-8db2-4e9c-8a46-b45a43858c4a, hostname=0.0.0.0]
[0x221be30]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x221be30]:0 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=test,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=test,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x221be30]: - AMQP
[0x221be30]:0 - @open(16) [container-id=7425ccf2-d216-40f5-a820-9772c0070ce8]
[0x221be30]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x221be30]:0 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x221be30]:0 - @detach(22) [handle=0, closed=true, error=@error(29)
[condition=:amqp:not-found, description=Node not found: test]]
LINK ERROR (amqp:not-found) Node not found: test
[0x221be30]:0 - @detach(22) [handle=0, closed=true]
[0x221be30]:0 - @close(24) []
[0x221be30]: - EOS
[0x221be30]: - EOS
[0x221be30]:0 - @close(24) []
[0x221be30]: - EOS
[0x221be30]: - EOS
[0x221be30]: - EOS
[0x221be30]: - EOS
{noformat}
On potentially another topic, is this expected:
https://gist.github.com/ssorj/10488102 . That's what happened when I
accidentally ran the test against qpidd without the 1.0 module. I'm surprised
that it surfaces as a SASL error. Let me know if I should file another jira.
Using the java broker, messenger apparently doesn't propagate error back from
broker to messenger
-
Key: PROTON-561
URL: https://issues.apache.org/jira/browse/PROTON-561
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6, 0.7
Reporter: Justin Ross
(The java broker logging for AMQP 1.0 is minimal; I'll mention that in
another jira.)
The test program below simply hangs. It didn't seem to want to time out,
either.
{noformat}
from proton import Message, Messenger
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5672/test
msg.body = test
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
By contrast, the same operation rendered in the qpid_messaging API produces
the expected error:
{noformat}
import sys
# You will need to build the swig python binding and point at it
sys.path.append(/home/jross/code/qpid/cpp/build/bindings/qpid/python)
from qpid_messaging import Connection
conn = Connection(0.0.0.0:5672, protocol=amqp1.0)
conn.open()
try:
session = conn.session()
sender = session.sender(test)
message = Message(test)
sender.send(message)
finally:
conn.close()
{noformat}
Error:
{noformat}
Traceback (most recent call last):
File /home/jross/test2.py, line 13, in module
sender = session.sender(test)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 560, in sender
s = self._sender(target)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 532, in _sender
def _sender(self, *args): return _qpid_messaging.Session__sender(self,
*args)
_qpid_messaging.NotFound: No such target : test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-683) Register Proton for Coverity scans
Justin Ross created PROTON-683: -- Summary: Register Proton for Coverity scans Key: PROTON-683 URL: https://issues.apache.org/jira/browse/PROTON-683 Project: Qpid Proton Issue Type: Task Components: proton-c, proton-j Reporter: Justin Ross For reference, the Qpid C++ and Java projects at Coverity: https://scan.coverity.com/projects/6 https://scan.coverity.com/projects/572 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-654) the proton page has no git info on it
[ https://issues.apache.org/jira/browse/PROTON-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-654. -- Resolution: Fixed Fixed at http://svn.apache.org/r1627791 the proton page has no git info on it - Key: PROTON-654 URL: https://issues.apache.org/jira/browse/PROTON-654 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Justin Ross -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-334) SASL Plug-in for Proton
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-334: --- Assignee: Andrew Stitcher SASL Plug-in for Proton --- Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318854#comment-14318854 ] Justin Ross commented on PROTON-808: I was suggesting the first answer on the SO page: You should look at set_target_properties command and the property BUILD_WITH_INSTALL_RPATH http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties I know now that you think that's simply the wrong thing to do. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318865#comment-14318865 ] Justin Ross commented on PROTON-808: Both problems have the same root cause, I believe. I don't think this is an unintentional defect. I think it's a question of policy and seeing what we can do to ease the path for the user. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318853#comment-14318853 ] Justin Ross commented on PROTON-808: No, it's about the install output. He just happens to be installing it to his home dir. From the SO question: When I run make install the program gets put in the correct place, but the cmake installer removes the runtime path from the binary. -- Install configuration: Debug -- Installing: *binary name* -- Removed runtime path from *binary name* Andrew thinks the right thing is to require the user to update the system ld configuration or override LD_LIBRARY_PATH. There is apparently a security motivation for this. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14319029#comment-14319029 ] Justin Ross commented on PROTON-808: I'll give it a try. I was hopeful install_rpath_use_link_path would work--strange. We should still decide whether it's a good idea at all. I like it from a user standpoint (that is, the default locates the library the user almost always wants), but Andrew had reason to think it was a bad idea. And Fedora strips rpaths from its rpm installed binaries. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-808) Binaries have their library locations stripped
Justin Ross created PROTON-808: -- Summary: Binaries have their library locations stripped Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[
https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295231#comment-14295231
]
Justin Ross commented on PROTON-808:
And this, which is really a worse problem:
{noformat}
[jross@localhost flurry]$ python
Python 2.7.8 (default, Nov 10 2014, 08:19:18)
[GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2
Type help, copyright, credits or license for more information.
from proton.handlers import *
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib64/proton/bindings/python/proton/__init__.py, line 33,
in module
from cproton import *
File /usr/local/lib64/proton/bindings/python/cproton.py, line 28, in
module
_cproton = swig_import_helper()
File /usr/local/lib64/proton/bindings/python/cproton.py, line 24, in
swig_import_helper
_mod = imp.load_module('_cproton', fp, pathname, description)
ImportError: libqpid-proton.so.2: cannot open shared object file: No such file
or directory
[jross@localhost flurry]$ echo $PYTHONPATH
/usr/local/lib64/proton/bindings/python
{noformat}
Binaries have their library locations stripped
--
Key: PROTON-808
URL: https://issues.apache.org/jira/browse/PROTON-808
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Justin Ross
1. Build proton
2. Install to /usr/local
3. Run proton
- Blows up, can't find its library
https://paste.apache.org/gd56
http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path
The default behavior of cmake is in my opinion wrong, and we should use the
fix mentioned in that stackoverflow discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-827) Reactive client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340690#comment-14340690 ] Justin Ross commented on PROTON-827: List discussion: https://issues.apache.org/jira/browse/PROTON-827 Reactive client binding for the go programming language. -- Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-827) Reactive client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340690#comment-14340690 ] Justin Ross edited comment on PROTON-827 at 2/27/15 7:46 PM: - List discussion: http://qpid.2158936.n2.nabble.com/PROTON-827-Reactive-client-binding-for-the-quot-go-quot-programming-language-td7621025.html was (Author: justi9): List discussion: https://issues.apache.org/jira/browse/PROTON-827 Reactive client binding for the go programming language. -- Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-818) Reactor C soak tests
[ https://issues.apache.org/jira/browse/PROTON-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345626#comment-14345626 ] Justin Ross commented on PROTON-818: Questions about how we might simplify the C reactor examples: http://qpid.2158936.n2.nabble.com/Proton-reactor-send-and-receive-tools-td7621405.html Reactor C soak tests Key: PROTON-818 URL: https://issues.apache.org/jira/browse/PROTON-818 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.9 Reporter: Cliff Jansen Assignee: Cliff Jansen Provide analogous programs to msgr-send and msgr-recv that can extend the soak tests to reactor sample programs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-818) Reactor C soak tests
[ https://issues.apache.org/jira/browse/PROTON-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335293#comment-14335293 ] Justin Ross commented on PROTON-818: https://reviews.apache.org/r/30898/ Reactor C soak tests Key: PROTON-818 URL: https://issues.apache.org/jira/browse/PROTON-818 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.9 Reporter: Cliff Jansen Assignee: Cliff Jansen Provide analogous programs to msgr-send and msgr-recv that can extend the soak tests to reactor sample programs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1029) Do not fail hard if strerror_r fails.
[ https://issues.apache.org/jira/browse/PROTON-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1029: Labels: crash (was: ) > Do not fail hard if strerror_r fails. > - > > Key: PROTON-1029 > URL: https://issues.apache.org/jira/browse/PROTON-1029 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: crash > Fix For: 0.11 > > > The return type from strerror_r differs depending on the compiler's feature > set. > if _GNU_SOURCE is defined, strerror_r returns a char * > if _POSIX_C_SOURCE is defined to a certain set of values, strerror_r returns > an int. > proton expects int, and fails hard (aborts) when a string ptr is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1029) Do not fail hard if strerror_r fails.
[ https://issues.apache.org/jira/browse/PROTON-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1029: Priority: Critical (was: Major) > Do not fail hard if strerror_r fails. > - > > Key: PROTON-1029 > URL: https://issues.apache.org/jira/browse/PROTON-1029 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Critical > Labels: crash > Fix For: 0.11 > > > The return type from strerror_r differs depending on the compiler's feature > set. > if _GNU_SOURCE is defined, strerror_r returns a char * > if _POSIX_C_SOURCE is defined to a certain set of values, strerror_r returns > an int. > proton expects int, and fails hard (aborts) when a string ptr is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1029) Do not fail hard if strerror_r fails.
[ https://issues.apache.org/jira/browse/PROTON-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978518#comment-14978518 ] Justin Ross commented on PROTON-1029: - Reviewed by Alan. Approved for 0.11.0. > Do not fail hard if strerror_r fails. > - > > Key: PROTON-1029 > URL: https://issues.apache.org/jira/browse/PROTON-1029 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Critical > Labels: crash > Fix For: 0.11 > > > The return type from strerror_r differs depending on the compiler's feature > set. > if _GNU_SOURCE is defined, strerror_r returns a char * > if _POSIX_C_SOURCE is defined to a certain set of values, strerror_r returns > an int. > proton expects int, and fails hard (aborts) when a string ptr is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1031) [python] Bump the module version to 0.11.0
[ https://issues.apache.org/jira/browse/PROTON-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978496#comment-14978496 ] Justin Ross commented on PROTON-1031: - Thanks, Ken. I missed that. Approved for 0.11.0. > [python] Bump the module version to 0.11.0 > -- > > Key: PROTON-1031 > URL: https://issues.apache.org/jira/browse/PROTON-1031 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.11 > > > Update the setup.py script and the module version number before we release > 0.11.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1026) Invalid queue/destination causes a segmentation fault
[ https://issues.apache.org/jira/browse/PROTON-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1026: Priority: Critical (was: Major) > Invalid queue/destination causes a segmentation fault > - > > Key: PROTON-1026 > URL: https://issues.apache.org/jira/browse/PROTON-1026 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 > Environment: Fedora Linux 22, 64bit. > > Using built-in specs. > COLLECT_GCC=/usr/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --enable-bootstrap > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > --enable-threads=posix --enable-checking=release --enable-multilib > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object --enable-linker-build-id > --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array > --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) > > Compiled with: > cmake -DCMAKE_INSTALL_PREFIX=/opt/devel/qpid-proton-0.11-SNAPSHOT > -DSYSINSTALL_BINDINGS=ON -DBUILD_PYTHON=OFF -DBUILD_PERL=OFF .. > --- >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Critical > Labels: crash > Fix For: 0.11 > > Attachments: proton-1026-backtrace.txt > > > Using an invalid path/destination in the address causes the code to crash > with SIGSEGV. > Having the QPid Proton code compiled, please use these teps to reproduce: > 1. Configure a broker > 2. Use the server example to send a message to a non-existent queue: > ./server -a server_address:5672/this_destination_does_no_exist -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1026) Invalid queue/destination causes a segmentation fault
[ https://issues.apache.org/jira/browse/PROTON-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1026: Labels: crash (was: ) > Invalid queue/destination causes a segmentation fault > - > > Key: PROTON-1026 > URL: https://issues.apache.org/jira/browse/PROTON-1026 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 > Environment: Fedora Linux 22, 64bit. > > Using built-in specs. > COLLECT_GCC=/usr/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --enable-bootstrap > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > --enable-threads=posix --enable-checking=release --enable-multilib > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object --enable-linker-build-id > --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array > --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) > > Compiled with: > cmake -DCMAKE_INSTALL_PREFIX=/opt/devel/qpid-proton-0.11-SNAPSHOT > -DSYSINSTALL_BINDINGS=ON -DBUILD_PYTHON=OFF -DBUILD_PERL=OFF .. > --- >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen > Labels: crash > Fix For: 0.11 > > Attachments: proton-1026-backtrace.txt > > > Using an invalid path/destination in the address causes the code to crash > with SIGSEGV. > Having the QPid Proton code compiled, please use these teps to reproduce: > 1. Configure a broker > 2. Use the server example to send a message to a non-existent queue: > ./server -a server_address:5672/this_destination_does_no_exist -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1027) Incorrectly handling of invalid addresses
[ https://issues.apache.org/jira/browse/PROTON-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1027: Fix Version/s: (was: 0.11) 0.12.0 > Incorrectly handling of invalid addresses > - > > Key: PROTON-1027 > URL: https://issues.apache.org/jira/browse/PROTON-1027 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 > Environment: Fedora Linux 22, 64bit. > > Using built-in specs. > COLLECT_GCC=/usr/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --enable-bootstrap > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > --enable-threads=posix --enable-checking=release --enable-multilib > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object --enable-linker-build-id > --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array > --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) > > Compiled with: > cmake -DCMAKE_INSTALL_PREFIX=/opt/devel/qpid-proton-0.11-SNAPSHOT > -DSYSINSTALL_BINDINGS=ON -DBUILD_PYTHON=OFF -DBUILD_PERL=OFF .. > --- >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > The code seems to accept invalid combinations of hosts/IPs. > Having the QPid Proton source code compile, you can run one of the following > to reproduce the problem: > A. Try to connect to to a server with an invalid ip address: > ./server -a 355.355.355.412:5672/test.reactor.queue > server connected to amqp://355.355.355.412:5672/test.reactor.queue > B. Try to connect to an invalid server whose address cannot be resolved: > ./server -a host_does_not_exist:5672/test.reactor.queue > server connected to amqp://host_does_not_exist:5672/test.reactor.queue > C. Try to connect to a valid server using an invalid port: > ./server -a valid-address:5672/test.reactor.queue > server connected to amqp://valid-address:5672/test.reactor.queue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1020) Typos in the error messages
[ https://issues.apache.org/jira/browse/PROTON-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1020: Fix Version/s: (was: 0.11) 0.12.0 > Typos in the error messages > --- > > Key: PROTON-1020 > URL: https://issues.apache.org/jira/browse/PROTON-1020 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Fix For: 0.12.0 > > Attachments: proton-1020-error-message-typos.patch > > > Some error messages in the files messaging_event.cpp and proton_bits.cpp > contain typos that should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1015) Documentation: typos in the C++ tutorial
[ https://issues.apache.org/jira/browse/PROTON-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1015. - Resolution: Fixed Fix Version/s: 0.11 > Documentation: typos in the C++ tutorial > > > Key: PROTON-1015 > URL: https://issues.apache.org/jira/browse/PROTON-1015 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Labels: documentation > Fix For: 0.11 > > Attachments: proton-1015-tutorial.patch > > > There are a few typos in the tutorial. I have quoted the phrases below and > *highlighted* the incorrect parts with to simplify. > ??Though often used in conjunction with a broker, AMQP does not require this. > It also allows senders and receivers *can* communicate directly if desired.?? > Description: I think we can replace _can_ with to. > ??The first difference, is that rather than creating a receiver on the same > connection as our sender, we listen for incoming connections by invoking the > proton::container::*Xblisten*() method on the container.?? > Description: The method _Xblisten()_ method does not exist. Shouldn't it be > listen()? > ??Note that for this example we *paick* an "unusual" port since we are > talking to ourselves rather than a broker.?? > Description: shouldn't it be _pick_? > ??This time we'll use an expected member variable for for the number of > messages we *expecct* and a received variable to count how many we have > received so far.*send.*?? > Description #1: shouldn't it be _expect_? > Description #2: it looks like the _send._ at the end of the phrase is a typo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-905: --- Fix Version/s: (was: 0.11) 0.12.0 > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming >Priority: Critical > Fix For: 0.12.0 > > Attachments: test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-985) Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock time
[ https://issues.apache.org/jira/browse/PROTON-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-985: --- Fix Version/s: (was: 0.11) 0.12.0 > Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock > time > - > > Key: PROTON-985 > URL: https://issues.apache.org/jira/browse/PROTON-985 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.12.0 > > > The timestamp argument to pn_transport_tick is a pn_timestamp_t. > pn_timestamp_t implies real time (wall clock) in that it's expressed as a > time value based on epoch. > As seen in QPID-6698, using a real time value for that argument can lead to > problems if the real time is adjusted (eg. timezone, daylight savings, > drift). > Instead, pn_transport_tick should be passed a monotonic clock source - one > that does not reflect changes in real time. > All documentation and examples should be updated accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 ] Justin Ross updated PROTON-949: --- Fix Version/s: 0.11 > 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 > Fix For: 0.11, 0.12.0 > > > 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] [Updated] (PROTON-1026) Invalid queue/destination causes a segmentation fault
[ https://issues.apache.org/jira/browse/PROTON-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1026: Fix Version/s: (was: 0.11) 0.12.0 > Invalid queue/destination causes a segmentation fault > - > > Key: PROTON-1026 > URL: https://issues.apache.org/jira/browse/PROTON-1026 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11 > Environment: Fedora Linux 22, 64bit. > > Using built-in specs. > COLLECT_GCC=/usr/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --enable-bootstrap > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > --enable-threads=posix --enable-checking=release --enable-multilib > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object --enable-linker-build-id > --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array > --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) > > Compiled with: > cmake -DCMAKE_INSTALL_PREFIX=/opt/devel/qpid-proton-0.11-SNAPSHOT > -DSYSINSTALL_BINDINGS=ON -DBUILD_PYTHON=OFF -DBUILD_PERL=OFF .. > --- >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Critical > Labels: crash > Fix For: 0.12.0 > > Attachments: proton-1026-backtrace.txt > > > Using an invalid path/destination in the address causes the code to crash > with SIGSEGV. > Having the QPid Proton code compiled, please use these teps to reproduce: > 1. Configure a broker > 2. Use the server example to send a message to a non-existent queue: > ./server -a server_address:5672/this_destination_does_no_exist -- 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=14997170#comment-14997170 ] Justin Ross commented on PROTON-949: Reviewed by Andrew. Approved for 0.11.0. > 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 > Fix For: 0.12.0 > > > 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-1042) Can't distinguish between null target and null address on a target
[ https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998548#comment-14998548 ] Justin Ross commented on PROTON-1042: - Reviewed and tested by Robbie. Approved for 0.11.0. > Can't distinguish between null target and null address on a target > -- > > Key: PROTON-1042 > URL: https://issues.apache.org/jira/browse/PROTON-1042 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.12.0 > > > In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the > source for pn_do_attach() in transport.c, it appears that 'target' is used to > hold the target address and if that is not specified (and the target is not > a coordinator, it is left as unspecified). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1037) Add support for setting/getting message properties
[ https://issues.apache.org/jira/browse/PROTON-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1037: Fix Version/s: 0.12.0 > Add support for setting/getting message properties > -- > > Key: PROTON-1037 > URL: https://issues.apache.org/jira/browse/PROTON-1037 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.11 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > Please add support for setting custom properties to a message in the C++ > reactive API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1039) Add support for setting/getting transport headers
[ https://issues.apache.org/jira/browse/PROTON-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1039: Fix Version/s: 0.12.0 > Add support for setting/getting transport headers > - > > Key: PROTON-1039 > URL: https://issues.apache.org/jira/browse/PROTON-1039 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.11 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > The C++ reactive API is missing the ability to get/set message transport > headers (ie.: durable, priority, ttl, 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 ] 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=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] [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] [Commented] (PROTON-512) Possibility to set idle timeout for messenger
[ https://issues.apache.org/jira/browse/PROTON-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982299#comment-14982299 ] Justin Ross commented on PROTON-512: The release notes are mistaken. I'm double checking the scripting now to make sure unresolved issues are filtered out. Thanks for catching this. > Possibility to set idle timeout for messenger > - > > Key: PROTON-512 > URL: https://issues.apache.org/jira/browse/PROTON-512 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Tomas Soltys > Labels: features, patch > Fix For: 0.9 > > Attachments: messenger.c.patch, messenger.h.patch > > > I would like to specify an idle timeout for a messenger which would be then > used for all created connections. I see that there is an interface for > pn_transport_t which is allowing it but it is not accessible from outside. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-512) Possibility to set idle timeout for messenger
[ https://issues.apache.org/jira/browse/PROTON-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-512: --- Issue Type: Improvement (was: Bug) > Possibility to set idle timeout for messenger > - > > Key: PROTON-512 > URL: https://issues.apache.org/jira/browse/PROTON-512 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.6 >Reporter: Tomas Soltys > Labels: features, patch > Fix For: 0.9 > > Attachments: messenger.c.patch, messenger.h.patch > > > I would like to specify an idle timeout for a messenger which would be then > used for all created connections. I see that there is an interface for > pn_transport_t which is allowing it but it is not accessible from outside. -- 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] [Created] (PROTON-1022) 0.11.0 release tasks
Justin Ross created PROTON-1022: --- Summary: 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)
[jira] [Created] (PROTON-1005) Factor anonymous-relay handling out of the examples
Justin Ross created PROTON-1005: --- Summary: Factor anonymous-relay handling out of the examples Key: PROTON-1005 URL: https://issues.apache.org/jira/browse/PROTON-1005 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Justin Ross http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/proton_server.py.html http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/server.py.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1001) Python tests fail in environments without unittest2
Justin Ross created PROTON-1001: --- Summary: Python tests fail in environments without unittest2 Key: PROTON-1001 URL: https://issues.apache.org/jira/browse/PROTON-1001 Project: Qpid Proton Issue Type: Bug Reporter: Justin Ross Provide compatibility with python 2.6: import unittest try: from unittest import SkipTest except: try: from unittest2 import SkipTest except: class SkipTest(Exception): pass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-803) Message codec improvements
[ https://issues.apache.org/jira/browse/PROTON-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-803: --- Fix Version/s: (was: 0.12.0) > Message codec improvements > -- > > Key: PROTON-803 > URL: https://issues.apache.org/jira/browse/PROTON-803 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.8 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > > This JIRA covers improvements made to the codec, especially lists and maps. > The work is based on > https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 > The above referenced code, is quite an improvement with respect to writing > lists, maps and strings over the existing codec. > Simply put the writeList and writeMap methods in the old encorder is about > ~10 times slower than the new encorder. > If I run with a sufficiently large set of strings, the old encorder is about > ~2 times slower than the new encorder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1071) EventInjector hangs on Windows
[ https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15086659#comment-15086659 ] Justin Ross commented on PROTON-1071: - We decided to go with option 1. > EventInjector hangs on Windows > -- > > Key: PROTON-1071 > URL: https://issues.apache.org/jira/browse/PROTON-1071 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.11.0 > Environment: Windows >Reporter: Ken Giusti >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > I added a new reactor test that exercises the python-proton ApplicationEvent > and EventInjector classes: > proton_tests.reactor.ApplicationEventTest.test_application_events > See tests/python/proton_tests/reactor.py > This test passes on linux, but hangs when run on Windows. > Poking around a bit, I suspect the problem may be in the Windows selector > code. Description: > The EventInjector/ApplicationEvent classes provide a way to trigger events > from threads external to the reactor main loop. See > proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the > reactor when a new event is sent to the reactor (see reactor.py in the python > bindings). The EventInjector's trigger method puts the event on a queue and > writes to a pipe to wake up the reactor. The on_selectable_readable callback > in the EventInjector is called on the reactor thread to get the event off the > queue and clear the pipe. > On windows it appears as if the EventInjector selectable is made "readable" > even though nothing has been written to the pipe. This causes the os.read() > call in the on_selectable_readable() callback to hang. > Best I can tell the windows selector code doesn't work properly with a pipe. > The pn_selector_next() function is returning a read event on the pipe's read > descriptor even though the pipe is empty. But I'm not familiar with the > window's selector implementation, so this is a best guess. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-999) Docs: pn_messenger_subscribe(): "source" is undocumented
[ https://issues.apache.org/jira/browse/PROTON-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-999: --- Labels: documentation messenger (was: documentation) > Docs: pn_messenger_subscribe(): "source" is undocumented > > > Key: PROTON-999 > URL: https://issues.apache.org/jira/browse/PROTON-999 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Graham Leggett >Assignee: Justin Ross > Labels: documentation, messenger > > The pn_messenger_subscribe() function is documented to take a const char * as > a "source": > https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6 > The definition of a "source" isn't specified, nor is the acceptable source > format specified. > In addition, it isn't specified in the docs whether this function must be > called once, or whether it can be called multiple times. Reverse engineering > the source seems to indicate that it should be called just once, and if you > call it multiple times the underlying event loop will be corrupted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-260) Messenger Documentation
[ https://issues.apache.org/jira/browse/PROTON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-260: --- Labels: messenger (was: ) > Messenger Documentation > --- > > Key: PROTON-260 > URL: https://issues.apache.org/jira/browse/PROTON-260 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.5 >Reporter: michael goulish >Assignee: michael goulish > Labels: messenger > > Write documentation for the Proton Messenger interface, to include: > introduction > API explanations > theory of operation > example programs > programming idioms > tutorials > quickstarts > troubleshooting > Documents should use MarkDown markup language. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-574: --- Labels: messenger patch (was: ) > proton-c: Messenger doesn't indicate when connection is aborted for a SASL > negotation failure > - > > Key: PROTON-574 > URL: https://issues.apache.org/jira/browse/PROTON-574 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Dominic Evans >Assignee: Andrew Stitcher > Labels: messenger, patch > Attachments: 05_return_sasl_auth_errors_messenger.c.patch, > 05_return_sasl_auth_errors_transport.c.patch, > 05_return_sasl_auth_errors_transport.h.patch > > > Currently if a Messenger's connection is aborted at the remote end, there's > no differentiation between the connection just being dropped and a failure to > negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-441) Provide hooks for alternative sources of Messenger routes
[ https://issues.apache.org/jira/browse/PROTON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-441. -- Resolution: Won't Fix > Provide hooks for alternative sources of Messenger routes > - > > Key: PROTON-441 > URL: https://issues.apache.org/jira/browse/PROTON-441 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.5 >Reporter: Ted Ross > Labels: messenger > > This is a request to add the capability to set Messenger routes automatically > on Messenger startup. Where the routes come from may be platform-specific > (i.e. environment variables, configuration files, registries, network-based > lookup, etc.). > The desire is to allow Messenger applications to be wholly unaware of the > route mappings that come from other sources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1041) Add recurring timer example to the reactive C++ documentation
[ https://issues.apache.org/jira/browse/PROTON-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1041: Fix Version/s: 0.12.0 > Add recurring timer example to the reactive C++ documentation > - > > Key: PROTON-1041 > URL: https://issues.apache.org/jira/browse/PROTON-1041 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0, 0.12.0 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Labels: patch > Fix For: 0.12.0 > > Attachments: recurring-timer-example.patch > > > The C++ documentation is missing the recurring_timer.cpp example in its > documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-544) Subscriptions have no documentation
[
https://issues.apache.org/jira/browse/PROTON-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-544:
---
Labels: messenger (was: )
> Subscriptions have no documentation
> ---
>
> Key: PROTON-544
> URL: https://issues.apache.org/jira/browse/PROTON-544
> Project: Qpid Proton
> Issue Type: Improvement
> Components: python-binding
>Affects Versions: 0.7
>Reporter: Justin Ross
> Labels: messenger
>
> For instance, you really want to know that when you do this:
> sub = msgr.subscribe("amqp://0.0.0.0/#")
> You have sub.address, so you can do this:
> msg = Message()
> msg.reply_to = sub.address
> The API doc for Messenger.subscribe says nothing about its return value, and
> Subscription is not among the classes in the generated API doc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-614) PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]: no valid sources'
[
https://issues.apache.org/jira/browse/PROTON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-614:
---
Labels: messenger php php-proton (was: php php-proton)
> PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]:
> no valid sources'
> ---
>
> Key: PROTON-614
> URL: https://issues.apache.org/jira/browse/PROTON-614
> Project: Qpid Proton
> Issue Type: Bug
> Components: php-binding
>Affects Versions: 0.7
> Environment: Ubuntu Linux on Amazon EC2
>Reporter: Jose Berardo Cunha
>Priority: Minor
> Labels: messenger, php, php-proton
>
> Sorry, but I don't know if it is really a bug or I'm doing something wrong.
> There is no documentation for Proton PHP, so here I am.
> Every time I try to execute recv.php sample I get this error:
> [0x16d2180]:ERROR[0] (null)
> [0x16d2180]:ERROR[0] (null)
> CONNECTION ERROR connection aborted (remote)
> PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]:
> no valid sources' in /usr/share/php/proton.php:61
> Stack trace:
> #0 /usr/share/php/proton.php(146): Messenger->_check(-5)
> #1 /home/ubuntu/qpid-proton-0.7/tests/smoke/recv.php(20): Messenger->recv()
> #2 {main}
> thrown in /usr/share/php/proton.php on line 61
> I've tried all of this command lines:
> $ php recv.php
> $ php recv.php "amqp://0.0.0.0"
> $ php recv.php "amqp://127.0.0.1"
> $ php recv.php "amqp://localhost"
> $ php recv.php "amqp://localhost:5672"
> $ php recv.php "amqp://localhost/myqueue"
> $ php recv.php "amqp://localhost:5672/myqueue"
> Where myqueue is my first queue created at Qpid 0.28 Web Console.
> I'got the same Connection aborted on send.php but what is weird is when I run
> send.php against an ActiveMQ Apollo broker I have no error message and I can
> see for just one or two seconds one line referring my message sent to it at
> its web console. So I presumed that send.php is able to connect an amqp
> broker but I don't know why it doesn't connect to Qpid 0.28.
> Please, What am I doing wrong, what are valid sources and where can I find
> more documentation about the Proton PHP library?
> Even the proton.php and cproton.php created by Swig have no comments.
> Thank you.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-886) make proton enforce handle-max
[ https://issues.apache.org/jira/browse/PROTON-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-886: --- Component/s: proton-j proton-c > make proton enforce handle-max > --- > > Key: PROTON-886 > URL: https://issues.apache.org/jira/browse/PROTON-886 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Reporter: michael goulish > > Make the code enforce limits on handles (and links) from section 2.7.2 of the > AMQP 1.0 spec. > The handle-max value is the highest handle value that can be used on the > session. A peer MUST NOT attempt to attach a link using a handle value > outside the range that its partner can handle. A peer that receives a handle > outside the supported range MUST close the connection with the framing-error > error-code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1057) Windows SChannel SSL test failure
[ https://issues.apache.org/jira/browse/PROTON-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1057: Labels: windows (was: ) > Windows SChannel SSL test failure > - > > Key: PROTON-1057 > URL: https://issues.apache.org/jira/browse/PROTON-1057 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 > Environment: Windows only. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > > This problem started since PROTON-1048 which did not touch the Proton-C > SChannel related code - it just tweaked the test infrastructure to use > alternate certificate formats for Windows. > The proton_tests.ssl.SslTest.test_server_hostname_authentication test > randomly crashes on Windows, presumably from some memory corruption > somewhere. It often runs fine. Seems to happen more frequently on some > systems than others. Not yet seen on a 64 bit build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-470) Perl bindings should have an interop test
[ https://issues.apache.org/jira/browse/PROTON-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-470: --- Assignee: (was: Darryl L. Pierce) > Perl bindings should have an interop test > - > > Key: PROTON-470 > URL: https://issues.apache.org/jira/browse/PROTON-470 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Darryl L. Pierce > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-342: --- Assignee: (was: Darryl L. Pierce) > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-451) PHP binding build failed with PHP5.5 (ZTS)
[ https://issues.apache.org/jira/browse/PROTON-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-451: --- Assignee: (was: Darryl L. Pierce) > PHP binding build failed with PHP5.5 (ZTS) > -- > > Key: PROTON-451 > URL: https://issues.apache.org/jira/browse/PROTON-451 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Debian 7 (amd64), PHP5.5.5 (built from source) >Reporter: Dmitrii Zolotov > > SWIG PHP binding compilation failed with following errors: > In file included from /usr/include/php/Zend/zend_alloc.h:27:0, > from /usr/include/php/Zend/zend.h:252, > from php_wrap.c:706: > php_wrap.c: In function ‘t_output_helper’: > /usr/include/php/Zend/../TSRM/TSRM.h:167:18: error: ‘tsrm_ls’ undeclared > (first use in this function) > #define TSRMLS_C tsrm_ls > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:168:21: note: in expansion of macro > ‘TSRMLS_C’ > #define TSRMLS_CC , TSRMLS_C > ^ > /usr/include/php/Zend/zend_gc.h:160:32: note: in expansion of macro > ‘TSRMLS_CC’ >gc_remove_zval_from_buffer(z TSRMLS_CC); \ > ^ > /usr/include/php/Zend/zend_gc.h:213:6: note: in expansion of macro > ‘GC_REMOVE_ZVAL_FROM_BUFFER’ > GC_REMOVE_ZVAL_FROM_BUFFER(z); \ > ^ > php_wrap.c:1154:5: note: in expansion of macro ‘FREE_ZVAL’ > FREE_ZVAL(o); > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:167:18: note: each undeclared identifier > is reported only once for each function it appears in > #define TSRMLS_C tsrm_ls > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:168:21: note: in expansion of macro > ‘TSRMLS_C’ > #define TSRMLS_CC , TSRMLS_C > ^ > /usr/include/php/Zend/zend_gc.h:160:32: note: in expansion of macro > ‘TSRMLS_CC’ >gc_remove_zval_from_buffer(z TSRMLS_CC); \ > ^ > /usr/include/php/Zend/zend_gc.h:213:6: note: in expansion of macro > ‘GC_REMOVE_ZVAL_FROM_BUFFER’ > GC_REMOVE_ZVAL_FROM_BUFFER(z); \ > ^ > php_wrap.c:1154:5: note: in expansion of macro ‘FREE_ZVAL’ > FREE_ZVAL(o); > ^ > I've tried to run swig manually (with php.i / cproton.i) and get the same > error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-437) Cmake fails to find Perl libraries on Ubuntu 11.10
[ https://issues.apache.org/jira/browse/PROTON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-437: --- Assignee: (was: Darryl L. Pierce) > Cmake fails to find Perl libraries on Ubuntu 11.10 > -- > > Key: PROTON-437 > URL: https://issues.apache.org/jira/browse/PROTON-437 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce > > Even with the FindPerlLibs module it is still failing to find the Perl > libraries on Ubuntu. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*
[ https://issues.apache.org/jira/browse/PROTON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-448: --- Assignee: (was: Darryl L. Pierce) > Ruby bindings need to have their set calls updated to properly map values to > pn_data_t* > --- > > Key: PROTON-448 > URL: https://issues.apache.org/jira/browse/PROTON-448 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Darryl L. Pierce > > When using the APIs in Qpid::Proton::Data I'm seeing: > irb(main):001:0> require 'qpid_proton' > => true > irb(main):002:0> data = Qpid::Proton::Data.new > => # > irb(main):003:0> data.ubyte = 3 > value=3 > TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16 > in SWIG method 'pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `ubyte=' > from (irb):3 > from /usr/bin/irb:12:in `' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-347) pn_messenger_set_timeout leads to send hanging
[ https://issues.apache.org/jira/browse/PROTON-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-347: --- Labels: messenger (was: ) > pn_messenger_set_timeout leads to send hanging > -- > > Key: PROTON-347 > URL: https://issues.apache.org/jira/browse/PROTON-347 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Latest SVN checkout as of this morning >Reporter: Frank Quinn > Labels: messenger > Attachments: qpid_messenger_timeout_failure.c > > > A non-negative pn_messenger_set_timeout seems to result in pn_messenger_send > hanging with the following backtrace: > Thread 2 (Thread 0x7fee4c037700 (LWP 16763)): > #0 0x003518ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x7fee4c079a42 in pn_driver_wait_2 () >from /usr/local/lib64/libqpid-proton.so.1 > #2 0x7fee4c079cea in pn_driver_wait () >from /usr/local/lib64/libqpid-proton.so.1 > #3 0x7fee4c0744e4 in pn_messenger_tsync () >from /usr/local/lib64/libqpid-proton.so.1 > #4 0x7fee4c0747dc in pn_messenger_sync () >from /usr/local/lib64/libqpid-proton.so.1 > #5 0x7fee4c076327 in pn_messenger_recv () >from /usr/local/lib64/libqpid-proton.so.1 > #6 0x00400d31 in qpidListenerThread () > #7 0x003519407d15 in start_thread (arg=0x7fee4c037700) > at pthread_create.c:308 > #8 0x003518cf248d in clone () > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 > Thread 1 (Thread 0x7fee4c039840 (LWP 16762)): > #0 0x003519408e60 in pthread_join (threadid=140661454239488, > ---Type to continue, or q to quit--- > thread_return=0x0) at pthread_join.c:92 > #1 0x00400f11 in main () -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-639) pn_messenger_recv hangs / spins on connection refused
[
https://issues.apache.org/jira/browse/PROTON-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-639:
---
Labels: messenger (was: )
> pn_messenger_recv hangs / spins on connection refused
> -
>
> Key: PROTON-639
> URL: https://issues.apache.org/jira/browse/PROTON-639
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7, 0.8
> Environment: Red Hat Enterprise Linux 6.5
> kernel: 2.6.32-431.1.2.el6.x86_64
> qpid-proton 0.7 and 9939b8a990cd53c1b5e099c083bdcf61ad22232b git-svn-id:
> https://svn.apache.org/repos/asf/qpid/proton/trunk@1613151
> 13f79535-47bb-0310-9956-ffa450edef68
>Reporter: Rohan McGovern
> Labels: messenger
>
> If I try to connect to a closed port with a messenger, pn_messenger_recv
> outputs messages to stderr and then spins at high CPU usage, rather than
> returning with an error as expected.
> This seems to be impacted by kernel version. I have a RHEL 6.5 machine which
> demonstrates this problem reliably when using kernel
> 2.6.32-431.1.2.el6.x86_64 and not when using 3.10.28-1.el6.elrepo.x86_64 .
> This can be easily reproduced using the "recv" example in the qpid-proton
> sources.
> {noformat:title=kernel 2.6.32 - broken}
> $ build/examples/messenger/c/recv amqp://127.0.0.1:1
> recv: Connection refused
> [0x63d8e0]:ERROR amqp:connection:framing-error SASL header mismatch: ''
> CONNECTION ERROR connection aborted (remote)
> # hangs at this point with high CPU usage
> {noformat}
> Compare with the behavior on a later kernel version, which seems right:
> {noformat:title=kernel 3.10.28 - expected behavior}
> $ build/examples/messenger/c/recv amqp://127.0.0.1:1
> recv: Connection refused
> [0x15af8e0]:ERROR amqp:connection:framing-error SASL header mismatch: ''
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> /home/rmcgover/src/qpid-proton/examples/messenger/c/recv.c:132: no valid
> sources
> # exits with exit code 1
> {noformat}
> Here's a sample backtrace when the hang is occurring:
> {noformat}
> (gdb) bt
> #0 0x77ffea11 in clock_gettime ()
> #1 0x003a51e03e46 in clock_gettime () from /lib64/librt.so.1
> #2 0x77de6b5e in pn_i_now () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #3 0x77de4c06 in pn_selector_select () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #4 0x77ddf736 in pni_wait () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #5 0x77ddf869 in pn_messenger_tsync () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #6 0x77ddf8df in pn_messenger_sync () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #7 0x77de1676 in pn_messenger_recv () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #8 0x004014b2 in main ()
> {noformat}
> There's a while(true) loop in pn_messenger_tsync which seems like it never
> escapes. strace also shows that the process is repeatedly doing a poll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-356) PHP bindings are not built on MacOS 10.8
[ https://issues.apache.org/jira/browse/PROTON-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-356: --- Labels: osx (was: ) > PHP bindings are not built on MacOS 10.8 > > > Key: PROTON-356 > URL: https://issues.apache.org/jira/browse/PROTON-356 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: MacOS X 10.8, Homebrew >Reporter: Serge Smertin >Priority: Critical > Labels: osx > > it's not possible to build PHP extension for MacOS, as it gives linking > error. Relates to issue - https://issues.apache.org/jira/browse/PROTON-108, > which is not resolved properly. > Short-term viable solution: > - Attach *.so files to this ticket for macos x exactly > Long-term solution: > - Make proper linking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-346) Deadlock experienced in pn_messenger_stop
[ https://issues.apache.org/jira/browse/PROTON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-346: --- Labels: messenger (was: ) > Deadlock experienced in pn_messenger_stop > - > > Key: PROTON-346 > URL: https://issues.apache.org/jira/browse/PROTON-346 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Frank Quinn >Priority: Critical > Labels: messenger > Attachments: qpid_deadlock_repro.c > > > Hi Folks, > See attached code: I'm encountering a deadlock when I try to stop messengers. > The general workflow is: > 1. Create pub and sub Messengers > 2. Start the Messengers > 3. Thread sub off onto its own thread as recv is a blocking call > 4. Publish round trip from the pub messenger to the sub messenger with a > destroy subject (recv is uninteruptable at the moment so this is our only to > interrupt it) > 5. Stop the messengers > When I try and stop the messengers, the application deadlocks with the > following backtrace (there is only one thread running at this point as the > subscribe thread has since exited): > Thread 1 (Thread 0x7f38181a4840 (LWP 6688)): > #0 0x003518ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00309c226a1c in poll (__timeout=, __nfds= out>, __fds=) > at /usr/include/bits/poll2.h:46 > #2 pn_driver_wait_2 (d=d@entry=0x1a81140, timeout=, > timeout@entry=-1) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:752 > #3 0x00309c226c42 in pn_driver_wait (d=0x1a81140, > timeout=timeout@entry=-1) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:807 > #4 0x00309c2242d3 in pn_messenger_tsync (messenger=0x1a81050, > predicate=0x309c222d80 , timeout=) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/messenger.c:623 > #5 0x00400ffb in main () at qpid_deadlock_repro.c:123 > I also tried adding the entire subscriber messenger workflow to the newly > created thread but the same behaviour persists (I'll be attaching the code to > recreate this shortly). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-395) Messenger - tracker-settled method is needed
[ https://issues.apache.org/jira/browse/PROTON-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-395: --- Labels: messenger (was: ) > Messenger - tracker-settled method is needed > > > Key: PROTON-395 > URL: https://issues.apache.org/jira/browse/PROTON-395 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: messenger > > Messenger has a way to query trackers to get the status of a message > delivery. However, there is no way to query the settlement of a delivery. > This is needed for the three-ack (exactly-once) exchange pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-782) pn_messenger_start always calls pn_messenger_resolve
[ https://issues.apache.org/jira/browse/PROTON-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-782: --- Labels: easyfix messenger (was: easyfix) > pn_messenger_start always calls pn_messenger_resolve > > > Key: PROTON-782 > URL: https://issues.apache.org/jira/browse/PROTON-782 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: David McCann > Labels: easyfix, messenger > Attachments: check_routes_only_when_specified.patch > > Original Estimate: 2m > Remaining Estimate: 2m > > Code was added to pn_messenger_start in 0.8 to allow a resolve to take place > immediately if PN_FLAGS_CHECK_ROUTES is set. > Unfortunately the check for the flag is incorrect, causing the resolve to > always take place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-388) Messenger lacks trace/debug logging
[ https://issues.apache.org/jira/browse/PROTON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-388: --- Labels: messenger (was: ) > Messenger lacks trace/debug logging > --- > > Key: PROTON-388 > URL: https://issues.apache.org/jira/browse/PROTON-388 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Affects Versions: 0.4 >Reporter: Ken Giusti > Labels: messenger > > There is no way to gain visibility into Messenger's internal state. We need > the ability to turn on trace logging to allow debugging messenger issues in > the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-201) Provide a C++ Messenger and Message class
[ https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-201. -- Resolution: Won't Fix > Provide a C++ Messenger and Message class > - > > Key: PROTON-201 > URL: https://issues.apache.org/jira/browse/PROTON-201 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Cliff Jansen > > Provide wrapper classes for these two types similar to what's available in > Perl and Ruby. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-938) [proton-J]Need ways to know temporary queue address created by Proton-J
[
https://issues.apache.org/jira/browse/PROTON-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-938:
---
Labels: documentation features messenger (was: documentation features)
> [proton-J]Need ways to know temporary queue address created by Proton-J
> ---
>
> Key: PROTON-938
> URL: https://issues.apache.org/jira/browse/PROTON-938
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.9.1
> Environment: Ubuntu Linux
>Reporter: yanfeng liu
> Labels: documentation, features, messenger
>
> It seems that Proton-J lacks the method to retrieve the address of a
> temporary queue created by Proton-J client application. The corresponding
> method exists in Proton-C like:
> {code:title=tempQueue.c|borderStyle=solid}
> // Subscribe w/ temp queue, print out the temp queue's name
> pn_subscription_t * sub = NULL;
> if ((sub = pn_messenger_subscribe(messenger, "amqps://10.69.3.1/#")) ==
> NULL) {
> printf("!!!queue %s does not exists\n",address);
> }
> printf("a subscribed address:%s\n",pn_subscription_address(sub));
> {code}
> However, in Proton-J, the Subscribe() method is defined as void.
> Regards,
> yf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-841) C recv example does not return disposition state
[ https://issues.apache.org/jira/browse/PROTON-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-841: --- Labels: messenger (was: ) > C recv example does not return disposition state > > > Key: PROTON-841 > URL: https://issues.apache.org/jira/browse/PROTON-841 > Project: Qpid Proton > Issue Type: Bug >Reporter: Matt Broadstone > Labels: messenger > > I apologize that I can't dig deeper into this for you, but I'm pressed for > time and figured it would still be meaningful feedback. I was recently > testing the rabbitmq amqp1.0 module against a number of amqp 1.0 clients, and > realized that when using the send/recv examples for the messenger api in > proton my recv client was disconnecting immediately after receiving a > message. > I submitted this > [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's > github and we traced the issue down to the fact that proton was not sending > back a state in the settled disposition frame upon receipt of the message > from the "send" client. The spec is incredibly ambiguous about what to do in > this scenario for brokers, and specifies that state is an optional field, but > at the same time the broker has no idea whether the message has been > acknowledged or rejects, simply that it has been settled. > Not sure how you guys want to go about this in your project, rabbitmq > gracefully handles this problem by closing the channel at this point (rather > than crashing as it did previously). > Anyway, just letting you know! > Cheers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-510) hostname field in the Open command is not set
[ https://issues.apache.org/jira/browse/PROTON-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088445#comment-15088445 ] Justin Ross commented on PROTON-510: [~tr...@redhat.com], has this changed? > hostname field in the Open command is not set > - > > Key: PROTON-510 > URL: https://issues.apache.org/jira/browse/PROTON-510 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Ted Ross > > If an address of the form "amqp://dns.domain.com/path" is used in > Proton/Messenger, when the connection is opened, the hostname field in the > Open should contain "dns.domain.com". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-344: --- Labels: message (was: ) > Need Ruby version of msgr-send/msgr-recv tools > -- > > Key: PROTON-344 > URL: https://issues.apache.org/jira/browse/PROTON-344 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: message > > A ruby variant of msgr-send/recv traffic generators should be added to the > soak tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-840) Fix Windows components to use transport logging
[ https://issues.apache.org/jira/browse/PROTON-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-840: --- Labels: windows (was: ) > Fix Windows components to use transport logging > --- > > Key: PROTON-840 > URL: https://issues.apache.org/jira/browse/PROTON-840 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8, 0.9 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > > Posix implemented new centralized logging. Windows needs to catch up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages
[
https://issues.apache.org/jira/browse/PROTON-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-766:
---
Labels: windows (was: )
> Proton-c Windows IO prints misleading error messages
>
>
> Key: PROTON-766
> URL: https://issues.apache.org/jira/browse/PROTON-766
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
> Environment: Windows Server 2012 R2
> Examples messaging c recv
>Reporter: Chuck Rolke
> Labels: windows
>
> Connecting to a port that is not open.
> Windows:
> {noformat}
> > send -a [::1]
> recv: No error
> [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch:
> ''
> CONNECTION ERROR connection aborted (remote)
> send: No error
> {noformat}
> The same action on Linux:
> {noformat}
> > ./send -a [::1]
> recv: Connection refused
> [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch:
> Insufficient data to determine protocol [''] (connection aborted)
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> {noformat}
> The Linux messages are more useful and indicate the precise error conditions.
> The Windows messages show recv: and send: with 'No error' and that is not the
> case.
> The same error message is displayed for IPv4 and IPv6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-599) Visual Studio warnings - enumeration update
[ https://issues.apache.org/jira/browse/PROTON-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-599: --- Labels: windows (was: ) > Visual Studio warnings - enumeration update > --- > > Key: PROTON-599 > URL: https://issues.apache.org/jira/browse/PROTON-599 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Visual Studio 2008, 2010, 2012, 2013 >Reporter: Chuck Rolke > Labels: windows > Attachments: vs-proton-warnings.txt > > > After suppressing the 'usual' warnings (see PROTON-546, > http://svn.apache.org/r1601010) and running some later compiler versions a > new list of errors emerges. Please see attached listing for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-598) CProton python binding fails to build Windows debug configuration
[ https://issues.apache.org/jira/browse/PROTON-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-598: --- Labels: windows (was: window) > CProton python binding fails to build Windows debug configuration > - > > Key: PROTON-598 > URL: https://issues.apache.org/jira/browse/PROTON-598 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Windows, Python 2.6.1 >Reporter: Chuck Rolke > Labels: windows > > cpython fails to link with file python26_d.lib not found. > The issue here is that the windows installer for python does not install the > debug versions (identified by the _d suffix) of the python libraries. Wisdom > from the web suggests either to build your own debug python or to debug using > a release build. > Links using the RelWithDebInfo work just fine and I can make progress running > ctest. Just a heads up for anyone who wants to run ctest with Debug builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[
https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-411:
---
Labels: windows (was: )
> [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
> -
>
> Key: PROTON-411
> URL: https://issues.apache.org/jira/browse/PROTON-411
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.4
> Environment: Windows
>Reporter: Chuck Rolke
> Labels: windows
>
> Windows needs something other than hard coded
> Libs: -L${libdir -lqpid-proton
> Cflags: -I${includedir}}
> All the other computed values configured into this file are correct: PREFIX,
> EXEC_PREFIX, LIBDIR, INCLUDEDIR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-405) [proton-c] Windows install fails to find proton-api.jar file
[ https://issues.apache.org/jira/browse/PROTON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-405: --- Labels: windows (was: ) > [proton-c] Windows install fails to find proton-api.jar file > > > Key: PROTON-405 > URL: https://issues.apache.org/jira/browse/PROTON-405 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows install >Reporter: Chuck Rolke > Labels: windows > > The install script is looking for file > 4> CMake Error at proton-j/proton-api/cmake_install.cmake:31 (FILE): > 4>file INSTALL cannot find > 4>"D:/Users/crolke/svn/proton/build/proton-j/proton-api/proton-api.jar". > but the actual file is versioned > Directory of D:\Users\chug\svn\proton\build\proton-j\proton-api > 08/17/2013 10:04 AM 120,690 proton-api-0.5.jar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1041) Add recurring timer example to the reactive C++ documentation
[ https://issues.apache.org/jira/browse/PROTON-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1041: Labels: patch (was: ) > Add recurring timer example to the reactive C++ documentation > - > > Key: PROTON-1041 > URL: https://issues.apache.org/jira/browse/PROTON-1041 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0, 0.12.0 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Labels: patch > Attachments: recurring-timer-example.patch > > > The C++ documentation is missing the recurring_timer.cpp example in its > documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-609) Assert in messenger.py test causes core dump
[
https://issues.apache.org/jira/browse/PROTON-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-609:
---
Labels: messenger (was: )
> Assert in messenger.py test causes core dump
>
>
> Key: PROTON-609
> URL: https://issues.apache.org/jira/browse/PROTON-609
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7
> Environment: Windows or Linux
>Reporter: Chuck Rolke
> Labels: messenger
>
> This assert:
> {noformat}
> Index: tests/python/proton_tests/messenger.py
> ===
> --- tests/python/proton_tests/messenger.py(revision 1602460)
> +++ tests/python/proton_tests/messenger.py(working copy)
> @@ -843,6 +843,7 @@
> msg2 = Message()
> msg2.address = self.address + "/msg2"
> self.client.put(msg2)
> +assert False, "Whoops!"
> self.pump()
> assert self.server.incoming == 1, self.server.incoming
> assert self.server.receiving == 8, self.server.receiving
> {noformat}
> causes a core dump in NBMessengerTest.teardown when the code tries to stop
> the client. A user may work around this issue by
> {noformat}
> + if msgr.outgoing > 0:
> +msgr.settle()
> + while msgr.incoming > 0:
> +msgr.get()
> + msgr.stop()
> {noformat}
> when all he wants is msgr.stop().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-568) messenger client slows and grows with large address space
[ https://issues.apache.org/jira/browse/PROTON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-568: --- Labels: messenger (was: ) > messenger client slows and grows with large address space > - > > Key: PROTON-568 > URL: https://issues.apache.org/jira/browse/PROTON-568 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish > Labels: messenger > > A messenger-based sending client grows from little memory to over 3 GB, and > slows down by at least 10x, when transmitting 1 message each to many > addresses. > here is the setup: > 1. a single messenger-based sender. > 2. a single dispatch router > 3. 5000 messenger-based receivers, each listening to 10 unique addresses. > i.e. 50,000 unique addresses total. > 4. the sender sends a single to each unique address. > 5. the first 10 messages go to addr1 ... addr10 -- all of which belong to the > first receiver. > 6. when each receiver gets all 10 of its messages, it shuts down. > 7. each message is 1-to-1, and fire-and-forget. > 8. This means that the sender only sends 1 message to each address and then > moves on, never to return. > Result > --- > The sending application started out doing something like 100-200 messages per > second. Its memory footprint was small. > By the time I reach 13,000 messages sent, output has fallen to about 25 > messages per second, and memory (RSS) has risen to about 1.7 GB. > It keeps getting larger and slower until the user rebels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-398) pn_messenger_subscribe() fails to create a listener
[
https://issues.apache.org/jira/browse/PROTON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-398:
---
Labels: messenger (was: )
> pn_messenger_subscribe() fails to create a listener
> ---
>
> Key: PROTON-398
> URL: https://issues.apache.org/jira/browse/PROTON-398
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, proton-j
>Affects Versions: 0.5
> Environment: linux (fedora 14 64bit)
>Reporter: Marc Berkowitz
> Labels: messenger
>
> Running a local ActiveMQ server, release 5.8.0, default configuration.
> The documented "listen all' feature of the python example fails with the error
> 'bind: Address already in use.'
> cd proton/examples/messenger/py;
> ./recv.py amqp://localhost/test -- subscribes to a specified address,
> and works
> ./recv.py OR ./recv.py amqp://~localhost -- listens to all addresses,
> and fails.
> py/recv.py amqp://~localhost
> Traceback (most recent call last):
> File "py/recv.py", line 41, in mng.subscribe(a)
> File "/usr/lib64/python2.7/site-packages/proton.py", line 371, in subscribe
> self._check(PN_ERR)
> File "/usr/lib64/python2.7/site-packages/proton.py", line 228, in _check
> raise exc("[%s]: %s" % (err, pn_messenger_error(self._mng)))
> proton.MessengerException: [-2]: unable to subscribe to source:
> amqp://~localhost
> (bind: Address already in use)
> Same error from a similar java program, which calls proton-j.
> Both fail trying to bind to localhost:5672, which is held by the local
> activemq server.
> Must either fix the ~ADDRESS feature or remove it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
