[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)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger->error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-571: --- Labels: messenger (was: ) > proton-c: Messenger outputs errors to stderr rather than setting > messenger->error > - > > Key: PROTON-571 > URL: https://issues.apache.org/jira/browse/PROTON-571 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Dominic Evans > Labels: messenger > Attachments: > 02_replace_perror_printing_with_error_setting_posix_driver.patch, > 02_set_pn_error_when_printing_connection_errors.patch, > 21_improve_perror_printing_io.h.patch, > 21_improve_perror_printing_messenger.c.patch, > 21_improve_perror_printing_posix_io.c.patch, > 21_improve_perror_printing_windows_io.c.patch > > > For various errors, such as aborted connections, messenger simply outputs > them to stderr rather then setting messenger->error. This makes it harder to > drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1043) Possible typo in messenger.c
[
https://issues.apache.org/jira/browse/PROTON-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1043:
Labels: messenger (was: )
> Possible typo in messenger.c
>
>
> Key: PROTON-1043
> URL: https://issues.apache.org/jira/browse/PROTON-1043
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Alan Conway
> Labels: messenger
>
> From mailing list:
> http://qpid.2158936.n2.nabble.com/Possible-typo-in-messenger-c-td7632895.html
>
> Is this an error:
> if (messenger->flags | PN_FLAGS_CHECK_ROUTES) {
> (line 1498 in messenger.c)?
> Shouldn't it be:
> if (messenger->flags & PN_FLAGS_CHECK_ROUTES) {
>
> In my opinion this comment is correct but I'm not an expert on messenger so
> wary of fixing without knowing if some of the code controlled by the if
> statement really should be running even if PN_FLAGS_CHECK_ROUTES is off.
> Clearly the code is incorrect as it stands I'm just uncertain if the fix
> suggested is safe or if the code needs review.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-142) Messenger has no unsubscribe
[ https://issues.apache.org/jira/browse/PROTON-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-142: --- Labels: messenger (was: ) > Messenger has no unsubscribe > > > Key: PROTON-142 > URL: https://issues.apache.org/jira/browse/PROTON-142 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Reporter: William Henry > Labels: messenger > > Doesn't Messenger need a: > void pn_messenger_unsubscribe(pn_subscription_t*) > It would see to be important. Is there a reason this does not exist? (besides > that it only recently got pn_subscription_t exposed) -- 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: --- Labels: features messenger patch (was: features patch) > 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, messenger, patch > 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-748) [PATCH] ruby: user doesn't have access to set settlement modes or messenger flags
[ https://issues.apache.org/jira/browse/PROTON-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-748: --- Labels: messenger (was: ) > [PATCH] ruby: user doesn't have access to set settlement modes or messenger > flags > - > > Key: PROTON-748 > URL: https://issues.apache.org/jira/browse/PROTON-748 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.8 >Reporter: Dominic Evans >Priority: Minor > Labels: messenger > Attachments: > 0001-Add-support-for-Messenger-snd-rcv-modes-and-flags.patch > > > Currently there's no way for a Ruby user to set the settlement modes or > behaviour flags used by the Messenger. > NB: the setting of outgoing_window / incoming_window in the patch are sort of > workarounds until I can establish why there is a check that those have been > initialized (from 0) at > https://github.com/apache/qpid-proton/blob/master/proton-c/src/messenger/messenger.c#L1724 > which means the settlement changes don't have any effect by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-423) Deadlock in messenger recv / send when send called from different threads (proton-c 0.5)
[ https://issues.apache.org/jira/browse/PROTON-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-423: --- Labels: me (was: ) > Deadlock in messenger recv / send when send called from different threads > (proton-c 0.5) > > > Key: PROTON-423 > URL: https://issues.apache.org/jira/browse/PROTON-423 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Linux x86 / pthread >Reporter: Frank Quinn > Labels: messenger > Attachments: qpid_messenger_deadlock.c > > > Hi Folks, > If I set a receive block to 1 message and in turn try to send to a > destination from multiple messengers on different threads, it seems to cause > a deadlock in send / recv. I have attached a small example which recreates > this: > This is the output we expect this application to produce: > Starting qpidListenerThread... > Waiting on data to come into pn_messenger_recv... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM MAIN THREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > Starting qpidSenderThread... > Finished with qpidSenderThread... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM PTHREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > This is what actually gets produced (note the second message is never > received) > Starting qpidListenerThread... > Waiting on data to come into pn_messenger_recv... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM MAIN THREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > Starting qpidSenderThread... > Which deadlocks with the following backtrace: > (gdb) thread apply all bt > Thread 3 (Thread 0xb77c9b70 (LWP 9431)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0021cca6 in poll () from /lib/libc.so.6 > #2 0x00c0f9fa in pn_driver_wait_2 () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #3 0x00c0fd9f in pn_driver_wait () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #4 0x00c0a4d1 in pn_messenger_tsync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #5 0x00c0a7bc in pn_messenger_sync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #6 0x00c0c27a in pn_messenger_recv () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #7 0x08048953 in qpidListenerThread () > #8 0x00355a49 in start_thread () from /lib/libpthread.so.0 > #9 0x00227aee in clone () from /lib/libc.so.6 > Thread 2 (Thread 0xb6dc8b70 (LWP 9432)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0021cca6 in poll () from /lib/libc.so.6 > #2 0x00c0f9fa in pn_driver_wait_2 () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #3 0x00c0fd9f in pn_driver_wait () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #4 0x00c0a4d1 in pn_messenger_tsync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #5 0x00c0a7bc in pn_messenger_sync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #6 0x00c0c1d5 in pn_messenger_send () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #7 0x08048a5d in qpidSenderThread () > #8 0x00355a49 in start_thread () from /lib/libpthread.so.0 > #9 0x00227aee in clone () from /lib/libc.so.6 > Thread 1 (Thread 0xb77ca990 (LWP 9430)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0035610d in pthread_join () from /lib/libpthread.so.0 > #2 0x08048bc9 in main () > Note that we know that this can be avoided by using the same messenger across > different threads for publishing or by setting a larger receive window, but > we expected this to work regardless and our existing implementation depends > on it. > Cheers, > Frank -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-247) provide configuration for messenger to disable sasl layer
[ https://issues.apache.org/jira/browse/PROTON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-247: --- Labels: messenger (was: ) > provide configuration for messenger to disable sasl layer > - > > Key: PROTON-247 > URL: https://issues.apache.org/jira/browse/PROTON-247 > Project: Qpid Proton > Issue Type: New Feature >Reporter: Rafael H. Schloming > Labels: messenger > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-423) Deadlock in messenger recv / send when send called from different threads (proton-c 0.5)
[ https://issues.apache.org/jira/browse/PROTON-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-423: --- Labels: messenger (was: me) > Deadlock in messenger recv / send when send called from different threads > (proton-c 0.5) > > > Key: PROTON-423 > URL: https://issues.apache.org/jira/browse/PROTON-423 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Linux x86 / pthread >Reporter: Frank Quinn > Labels: messenger > Attachments: qpid_messenger_deadlock.c > > > Hi Folks, > If I set a receive block to 1 message and in turn try to send to a > destination from multiple messengers on different threads, it seems to cause > a deadlock in send / recv. I have attached a small example which recreates > this: > This is the output we expect this application to produce: > Starting qpidListenerThread... > Waiting on data to come into pn_messenger_recv... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM MAIN THREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > Starting qpidSenderThread... > Finished with qpidSenderThread... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM PTHREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > This is what actually gets produced (note the second message is never > received) > Starting qpidListenerThread... > Waiting on data to come into pn_messenger_recv... > Data received by pn_messenger_recv... > Message received with subject: 'MESSAGE FROM MAIN THREAD' > Moving back to pn_messenger_recv > Waiting on data to come into pn_messenger_recv... > Starting qpidSenderThread... > Which deadlocks with the following backtrace: > (gdb) thread apply all bt > Thread 3 (Thread 0xb77c9b70 (LWP 9431)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0021cca6 in poll () from /lib/libc.so.6 > #2 0x00c0f9fa in pn_driver_wait_2 () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #3 0x00c0fd9f in pn_driver_wait () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #4 0x00c0a4d1 in pn_messenger_tsync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #5 0x00c0a7bc in pn_messenger_sync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #6 0x00c0c27a in pn_messenger_recv () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #7 0x08048953 in qpidListenerThread () > #8 0x00355a49 in start_thread () from /lib/libpthread.so.0 > #9 0x00227aee in clone () from /lib/libc.so.6 > Thread 2 (Thread 0xb6dc8b70 (LWP 9432)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0021cca6 in poll () from /lib/libc.so.6 > #2 0x00c0f9fa in pn_driver_wait_2 () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #3 0x00c0fd9f in pn_driver_wait () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #4 0x00c0a4d1 in pn_messenger_tsync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #5 0x00c0a7bc in pn_messenger_sync () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #6 0x00c0c1d5 in pn_messenger_send () >from /home/fquinn/lib/qpid-proton-0.5/lib/libqpid-proton.so.2 > #7 0x08048a5d in qpidSenderThread () > #8 0x00355a49 in start_thread () from /lib/libpthread.so.0 > #9 0x00227aee in clone () from /lib/libc.so.6 > Thread 1 (Thread 0xb77ca990 (LWP 9430)): > #0 0x00cc8424 in __kernel_vsyscall () > #1 0x0035610d in pthread_join () from /lib/libpthread.so.0 > #2 0x08048bc9 in main () > Note that we know that this can be avoided by using the same messenger across > different threads for publishing or by setting a larger receive window, but > we expected this to work regardless and our existing implementation depends > on it. > Cheers, > Frank -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-421) Support the PLAIN (and/or other) authentication method in the proton-j messenger
[ https://issues.apache.org/jira/browse/PROTON-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-421: --- Labels: messenger (was: ) > Support the PLAIN (and/or other) authentication method in the proton-j > messenger > > > Key: PROTON-421 > URL: https://issues.apache.org/jira/browse/PROTON-421 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.5 > Environment: all >Reporter: Jonathan Albrecht > Labels: messenger > > The proton-j messenger only supports anonymous authentication at the moment. > Lack of other mechanisms limits the messenger's usability especially with > message brokers. > A simple test is running the org.apache.qpid.proton.example Recv and Send > classes against the Qpid java broker. They work only if the AMQP port uses > anonymous authentication. With the default password file authentication they > fire a steady stream of exceptions like: > Sep 04, 2013 4:21:06 PM org.apache.qpid.proton.messenger.impl.MessengerImpl > processActive > SEVERE: Error processing connection > java.io.IOException: An established connection was aborted by the software in > your host machine > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(Unknown Source) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) > at sun.nio.ch.IOUtil.read(Unknown Source) > at sun.nio.ch.SocketChannelImpl.read(Unknown Source) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:127) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:93) > > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:502) > > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:617) > > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:585) > > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:254) > > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:259) > > at org.apache.qpid.proton.example.Recv.run(Recv.java:108) > at org.apache.qpid.proton.example.Recv.main(Recv.java:127) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-801) Add option to specify filter/selector in the subscribe method of Messenger API
[ https://issues.apache.org/jira/browse/PROTON-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-801: --- Labels: filter messenger selector (was: filter python, selector) > Add option to specify filter/selector in the subscribe method of Messenger API > -- > > Key: PROTON-801 > URL: https://issues.apache.org/jira/browse/PROTON-801 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.8 >Reporter: Jorge Maroto >Priority: Minor > Labels: filter, messenger, selector > > It would be nice to have a way of specifying filter/selectors for > subscriptions in the Messenger API instead of having to fallback to the > Protocol Engine API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-968) [proton-j] channel-max handling is broken
[ https://issues.apache.org/jira/browse/PROTON-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-968: --- Fix Version/s: 0.12.0 > [proton-j] channel-max handling is broken > - > > Key: PROTON-968 > URL: https://issues.apache.org/jira/browse/PROTON-968 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10 >Reporter: Robbie Gemmell > Fix For: 0.12.0 > > > The channel-max handling in proton-j is broken. > Transport[Impl] defines get/setChannelMax methods, which allow controlling > the value sent in the Open frame emmitted for the connection. It defaults to > the maximum 65535. > The ConnectionImpl object has a getMaxChannels method that returns a hard > coded value of 65535, and it is this limit value that is used by > TransportImpl when selecting local channel numbers for sending Begin frame > for new sessions. As such, it pays no notice of the limit value it announced > in its Open frame, which may have been lower if configured on the transport. > The remote channel-max receiver from the peer isn't used at all other than > for return via getRemoteChannelMax(). The above process will similarly pay it > no attention to it when selecting channel numbers for new sessions and so may > select a channel number above the remote peers limit [and perhaps also its > own, again]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-250) Add -fvisibility option when building shared libraries
[ https://issues.apache.org/jira/browse/PROTON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-250: --- Assignee: (was: Darryl L. Pierce) > Add -fvisibility option when building shared libraries > --- > > Key: PROTON-250 > URL: https://issues.apache.org/jira/browse/PROTON-250 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: GNU Compiler >Reporter: Irina Boverman >Priority: Minor > Attachments: proton.patch > > > Add an option to "hide" symbols in shared libraries except when they are > declared public. > Extends efforts already in place for Windows builds. > Excludes an effort to determine what symbols should be considered "public" > interfaces. > The gcc 4 -fvisibility option is said to: > ...very substantially improve linking and load times of shared object > libraries, produce more optimized code, provide near-perfect API export and > prevent symbol clashes. It is strongly recommended that you use this in any > shared objects you distribute. > See here: http://gcc.gnu.org/wiki/Visibility > Attached patch (patch.txt) will build libqpid-proton.so shared library using > this flag. > It reduces number of symbols from 700+ to 500+. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-169) Provide examples using web application frameworks
[ https://issues.apache.org/jira/browse/PROTON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-169: --- Assignee: (was: Darryl L. Pierce) > Provide examples using web application frameworks > - > > Key: PROTON-169 > URL: https://issues.apache.org/jira/browse/PROTON-169 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Darryl L. Pierce > > Provide examples for writing messaging web apps using Ruby on Rails, Django > and similar web technologies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-447) Ruby types returned from Data should carry their AMQP type
[ https://issues.apache.org/jira/browse/PROTON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-447: --- Assignee: (was: Darryl L. Pierce) > Ruby types returned from Data should carry their AMQP type > -- > > Key: PROTON-447 > URL: https://issues.apache.org/jira/browse/PROTON-447 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Darryl L. Pierce > > When a value is pulled out of a Qpid::Proton::Data type, such as a float or > integer, it should somehow carry with it its AMQP type. So, for example, if > the value returned is a ulong (represented as a Fixnum) then that should be > attached to the Fixnum so that it can potentially be put back into another > Data instance without losing that detail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-469) Perl recv.pl example displays garbage as the content of a message
[ https://issues.apache.org/jira/browse/PROTON-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-469: --- Assignee: (was: Darryl L. Pierce) > Perl recv.pl example displays garbage as the content of a message > - > > Key: PROTON-469 > URL: https://issues.apache.org/jira/browse/PROTON-469 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce > > Remove the call to content and only show the message body. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-768) DECIMAL32 values are not consistent in Ruby
[ https://issues.apache.org/jira/browse/PROTON-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-768: --- Assignee: (was: Darryl L. Pierce) > DECIMAL32 values are not consistent in Ruby > --- > > Key: PROTON-768 > URL: https://issues.apache.org/jira/browse/PROTON-768 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Reporter: Darryl L. Pierce >Priority: Minor > > On 32-bit EL6 running Ruby 1.8.7, DECIMAL32 values change. For example, the > following happened during running the rspec tests: > 2) A data object can hold a decimal32 >Failure/Error: expect(@data.decimal32).to eq(value) > > expected: 1161181977 > got: 1536795250 > > (compared using ==) ># ./spec/qpid/proton/data_spec.rb:304 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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: --- Labels: patch (was: ) > 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 > Labels: patch > Attachments: QPID-4106.patch > > > This bug was originally under the QPID jira instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-564) Messenger.work doesn't receive messages
[
https://issues.apache.org/jira/browse/PROTON-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed PROTON-564.
--
Resolution: Won't Fix
> Messenger.work doesn't receive messages
> ---
>
> Key: PROTON-564
> URL: https://issues.apache.org/jira/browse/PROTON-564
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: 0.6, 0.7
> Environment: Fedora 19, Python 2.7.5
>Reporter: Justin Ross
>
> Sink:
> {noformat}
> from proton import Messenger, Message
> msgr = Messenger()
> msgr.start()
> try:
> msgr.subscribe("amqp://~0.0.0.0:5")
> msg = Message()
> while True:
> print "Tick; incoming={}".format(msgr.incoming)
> msgr.work()
> # msgr.recv() XXX
>
> for i in range(msgr.incoming):
> msgr.get(msg)
> print(msg)
> finally:
> msgr.stop()
> {noformat}
> Source:
> {noformat}
> from proton import Messenger, Message
> msgr = Messenger()
> msgr.start()
> try:
> msg = Message()
> msg.address = "amqp://0.0.0.0:5/test"
> for i in range(10):
> print "Tick {}".format(i)
> msg.body = "Message {}".format(i)
> msgr.put(msg)
> msgr.send()
> finally:
> msgr.stop()
> {noformat}
> On 0.6, it blocks on one of the work calls with incoming always 0. On 0.7,
> it keeps looping through work calls with incoming always 0. The source sends
> nothing.
> Note the XXX bit in the sink. If you uncomment that. The sink consumes the
> messages.
> The python API documentation says the following:
> {noformat}
> Sends or receives any outstanding messages queued for a Messenger. This will
> block for the indicated timeout. This method may also do I/O work other than
> sending and receiving messages. For example, closing connections after
> messenger.stop() has been called.
> {noformat}
> Based on that, I expect that I should not need to call recv.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-391) Proton perl binding fails to build on OS X
[ https://issues.apache.org/jira/browse/PROTON-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-391: --- Labels: osx (was: ) > Proton perl binding fails to build on OS X > -- > > Key: PROTON-391 > URL: https://issues.apache.org/jira/browse/PROTON-391 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Environment: OS X >Reporter: Hiram Chirino > Labels: osx > > [ 71%] Building C object > proton-c/bindings/perl/CMakeFiles/cproton_perl.dir/perlPERL_wrap.c.o > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:26, > from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31, > from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:53: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_equals’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:65: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_list_remove’ > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31, > from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:73: error: > expected specifier-qualifier-list before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:111: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_next’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:112: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_prev’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:113: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_enter’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:114: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_exit’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:115: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_lookup’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:126: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:129: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:154: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_array_described’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:156: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_described’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:157: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_null’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:158: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_get_bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:187: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_restore’ > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:428: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_transport_quiesced’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:445: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_is_sender’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:446: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_is_receiver’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:455: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_advance’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:500: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_terminus_is_dynamic’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:501: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:519: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_delivery_settled’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:521: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_delivery_partial’ >
[jira] [Updated] (PROTON-438) proton-hawtdispatch tests fail on MacOS X
[ https://issues.apache.org/jira/browse/PROTON-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-438: --- Labels: osx (was: ) > proton-hawtdispatch tests fail on MacOS X > - > > Key: PROTON-438 > URL: https://issues.apache.org/jira/browse/PROTON-438 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.5 > Environment: MacOS X 10.8.5; Oracle Java 1.7.0_40 >Reporter: Marko Asplund > Labels: osx > Attachments: org.apache.qpid.proton.hawtdispatch.api.SampleTest.txt, > typescript.gz > > > proton-hawtdispatch tests fail On MacOS X: > (see attached log files for more information) > Caused by: java.lang.RuntimeException: java.io.IOException: Invalid argument > at > org.apache.qpid.proton.driver.impl.DriverImpl.doWait(DriverImpl.java:108) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:684) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:653) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:313) > at > org.apache.qpid.proton.hawtdispatch.test.MessengerServer$1.run(MessengerServer.java:48) > at java.lang.Thread.run(Thread.java:724) > Caused by: java.io.IOException: Invalid argument > at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method) > at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:200) > at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) > at > org.apache.qpid.proton.driver.impl.DriverImpl.doWait(DriverImpl.java:83) > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-345) Need a Java version of the msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-345: --- Labels: messenger (was: ) > Need a Java version of the msgr-send/msgr-recv tools > > > Key: PROTON-345 > URL: https://issues.apache.org/jira/browse/PROTON-345 > Project: Qpid Proton > Issue Type: Task > Components: proton-j >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: messenger > > A Java version of the msgr-send and msgr-recv traffic generator tools should > be added to the testbed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition
[
https://issues.apache.org/jira/browse/PROTON-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-824:
---
Labels: windows (was: )
> Windows fails testIdleTimeout with assert p.conn.remote_condition
> -
>
> Key: PROTON-824
> URL: https://issues.apache.org/jira/browse/PROTON-824
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.9
> Environment: Windows Server 2008 or 2012
> Visual studio 2010, x86
>Reporter: Chuck Rolke
> Labels: windows
>
> {noformat}
> 1: proton_tests.engine.ServerTest.testIdleTimeout .
> fail
> 1: Error during test: Traceback (most recent call last):
> 1: File "D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test",
> line 355, in run
> 1: phase()
> 1: File
> "D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py",
> line 1919 (or so), in testIdleTimeout
> 1: assert p.conn.remote_condition
> 1: AssertionError
> {noformat}
> Playing with Program explicit timeout (trying 10 instead of 3) gets the test
> to pass sometimes. It passes sometimes with 3 as well but normally fails.
> In debugging this it looks like there as no synchronization between what a
> test will show through print statements and what the proton library shows
> through PN_TRACE_FRM statements. Are there any hints to lining these up?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-407) [proton-c] Windows install does not install .lib nor .pdb files
[ https://issues.apache.org/jira/browse/PROTON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-407: --- Labels: windows (was: ) > [proton-c] Windows install does not install .lib nor .pdb files > --- > > Key: PROTON-407 > URL: https://issues.apache.org/jira/browse/PROTON-407 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: windows > > In current trunk building the INSTALL project in VS2010 does not place the > qpid-proton.lib, qpid-proton.pdb files into the install area. Consequently > consumers using an installed kit are unable to link to the qpid-proton > library. > In a dev environment the files are available in the build area as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-409) [proton-c] Windows .dll does not have embedded version resource
[ https://issues.apache.org/jira/browse/PROTON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-409: --- Labels: windows (was: ) > [proton-c] Windows .dll does not have embedded version resource > > > Key: PROTON-409 > URL: https://issues.apache.org/jira/browse/PROTON-409 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: windows > > Windows output objects may contain a version resource that allow the build > engineer to tag files with file and product resource numbers. Support for > this feature is missing. -- 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: window (was: ) > 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-546) C++ Windows warnings: conversions and possible loss of data
[ https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-546: --- Labels: windows (was: window) > C++ Windows warnings: conversions and possible loss of data > --- > > Key: PROTON-546 > URL: https://issues.apache.org/jira/browse/PROTON-546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Andrew Stitcher > Labels: windows > Attachments: PROTON-546-size-warnings.txt > > > Windows has other warnings similar to PROTON-545, especially during 64-bit > builds. > See attached file for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
[ https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-546: --- Labels: window (was: ) > C++ Windows warnings: conversions and possible loss of data > --- > > Key: PROTON-546 > URL: https://issues.apache.org/jira/browse/PROTON-546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Andrew Stitcher > Labels: windows > Attachments: PROTON-546-size-warnings.txt > > > Windows has other warnings similar to PROTON-545, especially during 64-bit > builds. > See attached file for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-310) [Proton-J] pipelined session opening and closing causes NPE on receipt of Begin
[
https://issues.apache.org/jira/browse/PROTON-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-310.
-
Resolution: Duplicate
Assignee: (was: Philip Harvey)
Closing this, it was later duplicated by PROTON-1017 but as the latter added a
test any work would probably be best done on the same JIRA.
> [Proton-J] pipelined session opening and closing causes NPE on receipt of
> Begin
> ---
>
> Key: PROTON-310
> URL: https://issues.apache.org/jira/browse/PROTON-310
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.4
>Reporter: Robbie Gemmell
>
> Pipelined session opening and closing causes NPE on receipt of Begin:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1033)
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1)
> at org.apache.qpid.proton.amqp.transport.Begin.invoke(Begin.java:144)
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1221)
> at
> org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:407)
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$1.input(SaslImpl.java:486)
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:170)
> at
> org.apache.qpid.proton.driver.impl.ConnectorImpl.processInput(ConnectorImpl.java:112)
> at
> org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:99)
> at
> org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:82)
>...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-810) Publish javascript binding on npm
[ https://issues.apache.org/jira/browse/PROTON-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-810. - Resolution: Fixed Closing out old issue, seems like something was done. > Publish javascript binding on npm > - > > Key: PROTON-810 > URL: https://issues.apache.org/jira/browse/PROTON-810 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.8 > Environment: NodeJS >Reporter: Matteo Murgida > Labels: javascript, nodejs, npm > Fix For: 0.9 > > > It would be very useful to the nodejs community to have the javascript > binding published on npm as "qpid-proton". > If you prefer, I can maintain that release for you :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1002) Cancelled timer tasks poison task pool
[ https://issues.apache.org/jira/browse/PROTON-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1002: --- Fix Version/s: 0.11.0 > Cancelled timer tasks poison task pool > -- > > Key: PROTON-1002 > URL: https://issues.apache.org/jira/browse/PROTON-1002 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.10.1, 0.11.0 > > > A cancelled task remains in cancelled state when reused from the pool. > The "new" task is scheduled pre-cancelled and has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-509) Proton build fails on OS X 10.9
[ https://issues.apache.org/jira/browse/PROTON-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-509: -- Fix Version/s: (was: 0.9) Removing 0.9 fix-version since it doesn't seem like anything was done via this JIRA for that release. This was obviously raised a long time ago. I'm unsure of the current state since I don't use OSX, but it would be good to get some CI set up to confirm, so leaving the JIRA open. > Proton build fails on OS X 10.9 > --- > > Key: PROTON-509 > URL: https://issues.apache.org/jira/browse/PROTON-509 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Hiram Chirino > > Build failure posted at: > https://gist.github.com/chirino/8823091 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-987) Do not assume clock_gettime is available - use system default if not.
[ https://issues.apache.org/jira/browse/PROTON-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-987: -- Fix Version/s: (was: 0.10.1) 0.11.0 > Do not assume clock_gettime is available - use system default if not. > - > > Key: PROTON-987 > URL: https://issues.apache.org/jira/browse/PROTON-987 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 >Reporter: Ken Giusti > Fix For: 0.11.0 > > > The python setup.py script assumes the system call clock_gettime is available > and always sets the USE_CLOCK_GETTIME compilation flag. Instead, it should > check for clock_gettime() and only set the flag if it is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-829) Possible reference counting bug in pn_clear_tpwork
[
https://issues.apache.org/jira/browse/PROTON-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-829:
--
Fix Version/s: (was: 0.9)
Removing 0.9 fix-version since it doesn't seem like anything was done there in
Proton, changes instead being made via QPID-6415.
> Possible reference counting bug in pn_clear_tpwork
> --
>
> Key: PROTON-829
> URL: https://issues.apache.org/jira/browse/PROTON-829
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
>Reporter: Alan Conway
>Assignee: Rafael H. Schloming
>
> See QPID-6415 which describes a core dump in the qpid tests that appears when
> using the current 0.9 proton master. The qpid tests pass OK with proton 0.8.
> The valgrind output in QPID-6415 shows that a connection is deleted while it
> is being finalized by a call from pn_connection_unbound to pn_clear_tpwork.
> I do not yet understand the details, but removing the following strange code
> fixes the problem and passes the proton test suite without valgrind errors:
> {noformat}
> --- a/proton-c/src/engine/engine.c
> +++ b/proton-c/src/engine/engine.c
> @@ -690,10 +690,10 @@ void pn_clear_tpwork(pn_delivery_t *delivery)
>{
> LL_REMOVE(connection, tpwork, delivery);
> delivery->tpwork = false;
> -if (pn_refcount(delivery) > 0) {
> - pn_incref(delivery);
> - pn_decref(delivery);
> -}
>}
> }
> {noformat}
> The code is strange because
> a) you should never examine a refcount except for debugging purposes
> b) under normal refcounting semantics incref+decref is a no-op.
> Is removing this code OK?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-777) [python] Url does not properly set default port if no scheme given
[ https://issues.apache.org/jira/browse/PROTON-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-777. - Resolution: Not A Problem Fix Version/s: (was: 0.9) Removing 0.9 fix-version and closing, comments suggest not-a-problem, nothing happened either way. > [python] Url does not properly set default port if no scheme given > -- > > Key: PROTON-777 > URL: https://issues.apache.org/jira/browse/PROTON-777 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming > > >>> import proton > >>> url = proton.Url(username='me', password='secret', host='myhost', > >>> path='foobar') > >>> str(url) > 'amqp://me:secret@myhost:amqp/foobar' > = > should be :5672 methinks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-635: -- Fix Version/s: (was: 0.9) Removing 0.9 fix-version since it doesn't seem like anything was done there. > PN_TRANSPORT events not generated in enough places > -- > > Key: PROTON-635 > URL: https://issues.apache.org/jira/browse/PROTON-635 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > In writing a custom driver for Proton I noticed thatthe new events code does > not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol > header. > So a purely event driven driver is not going to send the outgoing protocol > header immediately, but is going to wait until it replies to the next frame > (open). > Also in error scenarios no PN_TRANSPORT is generated after the open/close > frames are generated. > This is going to end badly if the peer is waiting for the protocol header > before sending the open. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-755) Update Ruby unit tests to use version 4.7 of Minitest
[ https://issues.apache.org/jira/browse/PROTON-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-755. - Resolution: Fixed Closing as 0.9 was long since released and it looks like something was done. > Update Ruby unit tests to use version 4.7 of Minitest > - > > Key: PROTON-755 > URL: https://issues.apache.org/jira/browse/PROTON-755 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Fix For: 0.9 > > > The old Test::Unit module names have been collapsed down to Minitest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-634) Packages are needed for Ubuntu Precise (12 LTS)
[ https://issues.apache.org/jira/browse/PROTON-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-634. - Resolution: Done Closing this one based on comment above. > Packages are needed for Ubuntu Precise (12 LTS) > --- > > Key: PROTON-634 > URL: https://issues.apache.org/jira/browse/PROTON-634 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.7 >Reporter: Ken Giusti >Priority: Minor > Fix For: 0.9 > > > Our PPA (ppa:qpid/released) only has proton packages for Ubuntu Trusty (14 > LTS). Ubuntu Precise (12 LTS) is still supported by upstream - we should > have packages for that also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15087099#comment-15087099 ] Pavel Moravec commented on PROTON-1090: --- Just a side-effect observation from the reproducer: testing it on downstream `python-qpid-proton-0.9-11.el7.x86_64`, I see also a memory consumption increase. I just run the reproducer and restart `qdrouterd` every 5 seconds. I even backported one known mem.leak there by applying these patches: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c799a29 https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bbba61a but the mem.increase persits. Since I dont have upstream version of proton reactor, the mem.leak can be already fixed in upstream. > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-994) Performance build/make targets for reactor C, and Python and C++ bindings
[ https://issues.apache.org/jira/browse/PROTON-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-994: -- Fix Version/s: 0.11.0 > Performance build/make targets for reactor C, and Python and C++ bindings > - > > Key: PROTON-994 > URL: https://issues.apache.org/jira/browse/PROTON-994 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.10.1 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.10.1, 0.11.0 > > > Create simple performance tests that can help identify performance wins or > regressions between commits or releases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-789) Lots of Deprecation Warnings on OSX
[ https://issues.apache.org/jira/browse/PROTON-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-789: -- Fix Version/s: (was: 0.9) Removing 0.9 fix-version since it doesn't seem like anything was done there. > Lots of Deprecation Warnings on OSX > --- > > Key: PROTON-789 > URL: https://issues.apache.org/jira/browse/PROTON-789 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 > Environment: Darwin gethsemane.local 14.0.0 Darwin Kernel Version > 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 > x86_64 >Reporter: Weston M. Price >Priority: Minor > Attachments: proton-build-osx.txt > > > Building proton-c on OS X 10.10.1 (Yosemite) gives quite a few deprecation > warnings, primarily in the SSL libraries. I have attached a file showing a > typical build run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-238) Initial CTest support
[ https://issues.apache.org/jira/browse/PROTON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-238. - Resolution: Fixed The cmake build uses ctest and has for ages, so this was presumably fixed at some point around the time of this JIRAs creation. Closing. > Initial CTest support > - > > Key: PROTON-238 > URL: https://issues.apache.org/jira/browse/PROTON-238 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.3 > Environment: Mainly proton-c and interop testing. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > This is a proposal for starting to use CMake's built in CTest capabilities in > order to allow a unified test mechanism on multiple platforms. > For the supplied review patch, it assumes that instead of using > trunk/config.sh and calling proton-test directly, you do: > cd path/to/trunk > mkdir build > cd build > cmake .. > make > ctest > Assuming the make succeeds, this will test two targets for now (proton-c and > proton-jni), but the newer proposed tests (i.e. performance) can be added as > well. > Once the desired work flow is captured, this can be tweaked to run in a > platform neutral way. CMake even has the capability to run CTest from inside > the Visual Studio IDE. Concepts and strategies are stolen from the qpid/cpp > tree. > By default, you just get a brief summary of the tests. Also try > ctest -V [ to see the full output ] > ctest -N [ to list the available tests ] > ctest -R proton-c [ just run the one test in this case, or a regexp if > supplied ] > ctest -E [ run all tests except ones that match regexp ] > Fancier tests can use cmake scripts to do things in a platform neutral manner > (move files around), run the test from a different directory, etc. Python > scripts and Java programs are already platform neutral, so there is no need > to make changes for those. > Tests can be conditionally configured (in the example proton-jni will not be > configured if maven or java aren't found). > Note that if you wish to just build and test proton-c, there is no > requirement to build from within the specific directory .../trunk/build. > This restriction currently exists for testing proton-jni using maven, but > perhaps that can be relaxed in future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1094) c++: refactor and documentation of type conversions
Alan Conway created PROTON-1094: --- Summary: c++: refactor and documentation of type conversions Key: PROTON-1094 URL: https://issues.apache.org/jira/browse/PROTON-1094 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.11.1 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.12.0 Original design was to use stream operator << >> interface to proton::data to give complete flexibility to construct/interpret arbitrary AMQP types in a usable, idiomatic C++ way. This interface is important internally but most API users will use automatic conversion via assignment, construction and get() functions on proton::value and the proton::scalar types. Move detailed documentation for the type conversion rules to proton::value, and mark the data interface as "advanced" but leave it available to cover possible interop cases that are not covered by the existing "canned" conversions. Review proton::message constructors, assignment and documentation to make sure it is easy to understand how to use data-containing members of a message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15087502#comment-15087502 ] Pavel Moravec commented on PROTON-1090: --- Yet another observation: the problem sounds to be on link level, not connection level (I *think*). I reproduced the same when having link routing in qdrouterd to qpid C++ broker, and the reproducer script in fact created a link via qdrouterd to qpidd. Then I was bouncing qpid _broker_. Not qdrouterd but qpidd. With lower probability than bouncing qdrouterd, I got spinning CPU and same backtraces. > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1091) [Python binding] AMQP null type not sent on wire according to AMQP specification
[ https://issues.apache.org/jira/browse/PROTON-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1091: Assignee: Kim van der Riet > [Python binding] AMQP null type not sent on wire according to AMQP > specification > > > Key: PROTON-1091 > URL: https://issues.apache.org/jira/browse/PROTON-1091 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.12.0 > > > When sending AMQP type null as the content of a message, the Python binding > sends the message with no body at all, and similarly interprets a no-body > AMQP type message as a null type. This violates the AMQP 1.0 specification on > two counts: > * A body MUST be present and be one of three types (section 3.2); > * When sending an AMQP null type, there is an assigned AMQP type code (0x40) > which should be used. > This causes interoperability issues with other clients. For example, the C++ > client can't send a null type to a python client without a failure (or _visa > versa_). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-589) Implement passive mode for proton-j messenger
[ https://issues.apache.org/jira/browse/PROTON-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-589. - Resolution: Won't Fix Closing out old issue, hasn't happened yet and doesn't seem likely to, someone can reopen or re-raise if it if needed. > Implement passive mode for proton-j messenger > - > > Key: PROTON-589 > URL: https://issues.apache.org/jira/browse/PROTON-589 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > > Passive mode allows the file descriptors for messenger to be serviced by an > external loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-244) NPE in org/apache/qpid/proton/jms/InboundTransformer when connecting qpid-client to qpid-proton in ActiveMQ
[ https://issues.apache.org/jira/browse/PROTON-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-244. - Resolution: Fixed Closing, there is a null check in there now so the issue was presumably fixed at some point. > NPE in org/apache/qpid/proton/jms/InboundTransformer when connecting > qpid-client to qpid-proton in ActiveMQ > --- > > Key: PROTON-244 > URL: https://issues.apache.org/jira/browse/PROTON-244 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.3 >Reporter: Jan-Helge Bergesen >Assignee: Hiram Chirino > Labels: robustness > Attachments: PROTON-244.logexcerpt.txt > > > Connecting a ConnectionFactory from qpid-amqp-1-0-client-jms version 0.20 to > ActiveMQ 5.8.0, yields NPE: > org.apache.activemq.transport.amqp.AmqpProtocolException: Could not process > AMQP commands > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter.onFrame(AmqpProtocolConverter.java:245) > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:151) > at > org.apache.activemq.transport.amqp.AmqpTransportFilter.onCommand(AmqpTransportFilter.java:94) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) > at > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.NullPointerException > at > org.apache.qpid.proton.jms.InboundTransformer.populateMessage(InboundTransformer.java:146) > at > org.apache.qpid.proton.jms.AMQPNativeInboundTransformer.transform(AMQPNativeInboundTransformer.java:37) > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter$ProducerContext.onMessage(AmqpProtocolConverter.java:454) > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter$BaseProducerContext.onDelivery(AmqpProtocolConverter.java:435) > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter.onFrame(AmqpProtocolConverter.java:215) > ... 6 more > Looking at > https://github.com/apache/qpid-proton/blob/trunk/proton-j/contrib/proton-jms/src/main/java/org/apache/qpid/proton/jms/InboundTransformer.java#L146 > It would seems that qpid-amqp-1-0-client-jms sends a message with header > "x-opt-jms-type" with value NULL. > This might very well be an invalid combination of client/broker setup -- > however, the proton-jms code could possibly benefit from utilizing > String.valueOf(..) instead of getValue().toString() (or similar) :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-333) Messenger does x.509 authentication without SASL EXTERNAL mechanism
[ https://issues.apache.org/jira/browse/PROTON-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-333: --- Labels: messenger (was: ) > Messenger does x.509 authentication without SASL EXTERNAL mechanism > --- > > Key: PROTON-333 > URL: https://issues.apache.org/jira/browse/PROTON-333 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: messenger > > When using SSL certificates for client authentication, Messenger uses the > ANONYMOUS mechanism in SASL. This is non-standard (as I understand it). The > EXTERNAL mechanism should be used at the SASL layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-855) Add axTLS (embedded SSL) support to proton-c
[ https://issues.apache.org/jira/browse/PROTON-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-855: --- Assignee: Andrew Stitcher (was: Justin Ross) > Add axTLS (embedded SSL) support to proton-c > > > Key: PROTON-855 > URL: https://issues.apache.org/jira/browse/PROTON-855 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: Platform independent >Reporter: Tomasz Nowicki >Assignee: Andrew Stitcher > Labels: features > Fix For: 0.12.0 > > Attachments: axtls.c, axtls_proton_example.c, qpidproton-AXTLS.patch, > ssl_io.h > > Original Estimate: 0h > Remaining Estimate: 0h > > The axTLS embedded SSL project is a highly configurable client/server > TLSv1 SSL library designed for platforms with small memory requirements. > It comes with a small HTTP/HTTPS server and additional test tools. > axTLS It's free! (BSD style licensing) > http://axtls.sourceforge.net/ > axTLS integration with proton is done on socket layer(posix layer). On the > other hand OpenSSL integration with proton is done on the transport layer. To > use both solutions we had to add two methods pn_ssl_recv i pn_ssl_send > (daclared in include/ssl_io.h) which in openssl mode, without crypting, > invoke native proton "pn_send" and "pn_receive (io.c)". In axTLS mode, those > methods are replaced with proper axtls comunication methods. Those are > defined in openssl.c, ssl_stub.c, axtls.c and located in src/ssl. > Methods pn_ssl_recv and pn_ssl_send replace original pn_send and pn_recv used > in pni_connection_writable(pn_selectable_t *sel), > pni_connection_readable(pn_selectable_t *sel) (connection.c). > Moreover we introduced new file axtls.c located in src/ssl. The file is an > equivalent of openssl.c, implementing base ssl methods: PN_EXTERN > pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t mode); > PN_EXTERN void pn_ssl_domain_free( pn_ssl_domain_t *domain ); etc > Example of axTLS integration with ex ActiveMQ > atatched(axtls_proton_example.c): > It's based on > http://mail-archives.us.apache.org/mod_mbox/qpid-proton/201501.mbox/%3ccacl1bnc5jerbnikd_4fgkjqh13h5nl_2z-sszp3jg2t+ywa...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-422) proton-c proton-j Messenger send and receive compatibility
[
https://issues.apache.org/jira/browse/PROTON-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-422.
-
Resolution: Cannot Reproduce
Closing out old issue, wasn't able to reproduce previously.
> proton-c proton-j Messenger send and receive compatibility
> ---
>
> Key: PROTON-422
> URL: https://issues.apache.org/jira/browse/PROTON-422
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, proton-j
>Affects Versions: 0.5
> Environment: Windows 7, JDK 7, JDK 6
>Reporter: Sahal Zain
>Assignee: Robbie Gemmell
>
> I was testing the example of proton-c and proton-j for both receive and send
> functionality. On the same code (c to c and java to java) it's work
> flawlessly. The problem occur when I'm using proton-j as a reciever and
> proton-c as a sender, in JDK 7 it's not work, while in JDK 6, sometimes it
> work (but mostly not work). But it also work fine if I'm using proton-c as a
> receiver and proton-j as a sender.
> Below is the message log when I'm sending with proton-c sender :
> FINE: Processing active connector ConnectorImpl
> [_channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:5672
> remote=/127.0.0.1:49625]]
> Sep 09, 2013 9:40:40 AM org.apache.qpid.proton.engine.impl.FrameParser input
> FINE: IN: CH[0] : Transfer{handle=0, deliveryId=0,
> deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x00, messageFormat=0, settled=true,
> more=false, rcvSettleMode=null, state=null, resume=false, aborted=false,
> batchable=false}[\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00g\x00\x00\x00\x0d@@\xa1\x13amqp://0.0.0.0/test\xa1\x04test\xa1+amqp://c29e810a-d645-4edb-962e-01dcb43f5b11@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!]
> Sep 09, 2013 9:40:40 AM org.apache.qpid.proton.engine.impl.FrameParser input
> FINE: IN: CH[0] : Detach{handle=0, closed=true, error=null}
> Sep 09, 2013 9:40:40 AM org.apache.qpid.proton.engine.impl.FrameParser input
> FINE: IN: CH[0] : Close{error=null}
> Sep 09, 2013 9:40:40 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> processActive
> FINE: Processing active connector ConnectorImpl
> [_channel=java.nio.channels.SocketChannel[closed]]
> For comparison, below is the message log when I'm sending the message with
> proton-j sender:
> FINE: Processing active connector ConnectorImpl
> [_channel=java.nio.channels.SocketChannel[connected local=/10.8.93.56:5672
> remote=/10.8.93.56:49629]]
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.engine.impl.FrameParser input
> FINE: IN: CH[0] : Transfer{handle=0, deliveryId=0, deliveryTag=1,
> messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
> resume=false, aborted=false,
> batchable=false}[\x00Ss\xc0K\x05@@\xa1\x13amqp://0.0.0.0/test\xa1\x04Test\xa1+amqp://24439c22-1f01-412a-8ae2-86a9bd239ea7\x00Sw\xa1\x0eHello
> World!!!]
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> get
> FINE: Attempting to get message from EndpointImpl [_localState=ACTIVE,
> _remoteState=ACTIVE, _localError=Error{condition=null, description='null',
> info=null}, _remoteError=Error{condition=null, description='null', info=null}]
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> get
> FINE: Readable delivery found: DeliveryImpl [_tag=[49], _link=EndpointImpl
> [_localState=ACTIVE, _remoteState=ACTIVE, _localError=Error{condition=null,
> description='null', info=null}, _remoteError=Error{condition=null,
> description='null', info=null}], _deliveryState=null, _settled=false,
> _remoteSettled=true, _remoteDeliveryState=null, _flags=4,
> _transportDelivery=org.apache.qpid.proton.engine.impl.TransportDelivery@60bb94d9,
> _dataSize=99, _complete=true, _updated=true, _done=false, _offset=0]
> message: 1
> Address: amqp://0.0.0.0/test
> Subject: Test
> Headers: null
> AmqpValue{Hello World!!!}
> END
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> recv
> FINE: MessengerImpl [_name=544e183e-e802-438b-92b0-ce52b4228c1f] about to
> wait for up to -1 messages to be received
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> processActive
> FINE: Processing active connector ConnectorImpl
> [_channel=java.nio.channels.SocketChannel[connected local=/10.8.93.56:5672
> remote=/10.8.93.56:49629]]
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.engine.impl.FrameParser input
> FINE: IN: CH[0] : Close{error=null}
> Sep 09, 2013 9:41:30 AM org.apache.qpid.proton.messenger.impl.MessengerImpl
> processActive
> FINE: Processing active connector ConnectorImpl
> [_channel=java.nio.channels.SocketChannel[closed]]
>
--
This message was sent by
[jira] [Closed] (PROTON-211) Non-maven users should have ability to run all system tests
[ https://issues.apache.org/jira/browse/PROTON-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-211. - Resolution: Won't Fix Closing old JIRA. The cmake build runs all the tests if possible, including the java builds using Maven if available. > Non-maven users should have ability to run all system tests > --- > > Key: PROTON-211 > URL: https://issues.apache.org/jira/browse/PROTON-211 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Reporter: Keith Wall > > Non-maven users (those building proton-c, the bindings etc using cmake, make > etc) should have a simple method to run all the system tests including those > written in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-226) Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode.
[ https://issues.apache.org/jira/browse/PROTON-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-226. - Resolution: Fixed Closing this as comment indicates it is likely fixed via duplicate PROTON-402, and there has been no activity on the JIRA since. > Porting Issue -- Heap Corruption using Visual Studio when running > client/server proton in debug mode. > - > > Key: PROTON-226 > URL: https://issues.apache.org/jira/browse/PROTON-226 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > > Code changes for windows port were added (MinGW and Visual Studio) to the > proton codebase recently. > Using the new codebase and some additional changes, I ran the proton > executable using the Visual Studio toolset as both a server and client. When > the client exits, a Windows popup displays: > "Windows has triggered a breakpoint in proton.exe. > This may be due to a corruption of the heap, which indicates a bug in > proton.exe or any of the DLLs it has loaded." > Still tracking this problem down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-150) [Proton-J] Surface necessary methods in interface to remove need to cast to Impl
[ https://issues.apache.org/jira/browse/PROTON-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-150. - Resolution: Done I think some work was done here. Closing the JIRA in any case as it hasnt been touched in a while and no specific instances are noted. New JIRAs can be raised as needed for any specific changes required. > [Proton-J] Surface necessary methods in interface to remove need to cast to > Impl > > > Key: PROTON-150 > URL: https://issues.apache.org/jira/browse/PROTON-150 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-789) Lots of Deprecation Warnings on OSX
[ https://issues.apache.org/jira/browse/PROTON-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-789: --- Labels: osx (was: ) > Lots of Deprecation Warnings on OSX > --- > > Key: PROTON-789 > URL: https://issues.apache.org/jira/browse/PROTON-789 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 > Environment: Darwin gethsemane.local 14.0.0 Darwin Kernel Version > 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 > x86_64 >Reporter: Weston M. Price >Priority: Minor > Labels: osx > Attachments: proton-build-osx.txt > > > Building proton-c on OS X 10.10.1 (Yosemite) gives quite a few deprecation > warnings, primarily in the SSL libraries. I have attached a file showing a > typical build run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-486) Create a User's Guide
[ https://issues.apache.org/jira/browse/PROTON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-486: --- Fix Version/s: 0.12.0 > Create a User's Guide > - > > Key: PROTON-486 > URL: https://issues.apache.org/jira/browse/PROTON-486 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andreas Mueller >Assignee: Justin Ross > Fix For: 0.12.0 > > > What would really helpful is a one-page user guide where you explain the > Messenger API. I want to know e.g. how to use the different QoS exactly-once, > at-most-once, at-least-once and all that stuff I can do with that API without > jumping from one header file to another and need to ask questions in mailing > lists. Provide basic samples with snippets in the different supported > language bindings. > I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. > This is how our client is documented: > http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html > That's it. Doesn't took much effort to create it. > Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went > frustrated away from it because they don't understand the basic concepts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-161: --- Priority: Minor (was: Critical) > SSL impl does not allow verification of the peer's identity > --- > > Key: PROTON-161 > URL: https://issues.apache.org/jira/browse/PROTON-161 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Philip Harvey >Priority: Minor > Labels: security > > The current SSL implementation validates the peer's certificate, and will not > permit the connection to come up if the certificate is invalid. > However - it does not provide a way to check if the peer's identity as > provided in the certificate is the expected identity (eg, the same hostname > used to set up the TCP connection). While a certificate may be valid (that > is, signed by a CA trusted by the client), it may not belong to the intended > destination. > RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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:
---
Labels: messenger (was: )
> 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
> Labels: messenger
>
> (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
> 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.3.4#6332)
[jira] [Updated] (PROTON-390) Suppress or Fix the warnings openssl.c produce
[ https://issues.apache.org/jira/browse/PROTON-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-390: --- Labels: osx (was: ) > Suppress or Fix the warnings openssl.c produce > -- > > Key: PROTON-390 > URL: https://issues.apache.org/jira/browse/PROTON-390 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Environment: OS X >Reporter: Hiram Chirino > Labels: osx > > openssl.c produces lots of warnings. > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘_log_ssl_error’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:165: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:167: warning: > ‘ERR_error_string_n’ is deprecated (declared at > /usr/include/openssl/err.h:280) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:169: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘ssl_failed’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:189: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:191: warning: > ‘ERR_error_string_n’ is deprecated (declared at > /usr/include/openssl/err.h:280) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘verify_callback’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:257: warning: > ‘X509_STORE_CTX_get_error_depth’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:453) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:261: warning: > ‘X509_STORE_CTX_get_current_cert’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:454) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: > ‘X509_STORE_CTX_get_ex_data’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:450) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: > ‘SSL_get_ex_data_X509_STORE_CTX_idx’ is deprecated (declared at > /usr/include/openssl/ssl.h:1601) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:268: warning: > ‘SSL_get_ex_data’ is deprecated (declared at /usr/include/openssl/ssl.h:1587) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:285: warning: > ‘X509_get_ext_d2i’ is deprecated (declared at > /usr/include/openssl/x509.h:1151) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:287: warning: > ‘sk_num’ is deprecated (declared at /usr/include/openssl/stack.h:81) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:290: warning: > ‘sk_value’ is deprecated (declared at /usr/include/openssl/stack.h:82) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:295: warning: > ‘ASN1_STRING_to_UTF8’ is deprecated (declared at > /usr/include/openssl/asn1.h:981) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:299: warning: > ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:308: warning: > ‘X509_get_subject_name’ is deprecated (declared at > /usr/include/openssl/x509.h:1013) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:310: warning: > ‘X509_NAME_get_index_by_NID’ is deprecated (declared at > /usr/include/openssl/x509.h:1105) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:311: warning: > ‘X509_NAME_get_entry’ is deprecated (declared at > /usr/include/openssl/x509.h:1108) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:312: warning: > ‘X509_NAME_ENTRY_get_data’ is deprecated (declared at > /usr/include/openssl/x509.h:1130) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:315: warning: > ‘ASN1_STRING_to_UTF8’ is deprecated (declared at > /usr/include/openssl/asn1.h:981) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:319: warning: > ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:329: warning: > ‘X509_STORE_CTX_set_error’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:452) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘get_dh2048’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:371: warning: > ‘DH_new’ is deprecated (declared at /usr/include/openssl/dh.h:184) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:372: warning: > ‘BN_bin2bn’ is deprecated (declared at /usr/include/openssl/bn.h:422) >
[jira] [Closed] (PROTON-732) assertion in transport_consume when authentication fails: Assertion `n == (-1)' failed
[ https://issues.apache.org/jira/browse/PROTON-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-732. - Resolution: Fixed > assertion in transport_consume when authentication fails: Assertion `n == > (-1)' failed > -- > > Key: PROTON-732 > URL: https://issues.apache.org/jira/browse/PROTON-732 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim > > Running the messenger recv example against the java broker (both from latest > trunk at time of raising this issue), if the broker expects authentication > and you don't specify a username and password then the resulting sequence > causes an assertion in the proton-c library. > $ PN_TRACE_FRM=1 ./examples/messenger/c/recv amqp://localhost > [0xc6eb00]: -> SASL > [0xc6eb00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""] > [0xc6eb00]: <- SASL > [0xc6eb00]:0 <- @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:AMQPLAIN, :PLAIN, :"CRAM-MD5"]] > [0xc6eb00]:0 <- @sasl-outcome(68) [code=1] > recv: /home/gordon/projects/proton/proton-c/src/transport/transport.c:1070: > transport_consume: Assertion `n == (-1)' failed. > Aborted (core dumped) > Core was generated by `./examples/messenger/c/recv amqp://localhost'. > Program terminated with signal 6, Aborted. > #0 0x003d54635935 in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install glibc-2.15-59.fc17.x86_64 > keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10.2-12.fc17.x86_64 > libcom_err-1.42.3-3.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 > libuuid-2.21.2-4.fc17.x86_64 openssl-1.0.0k-1.fc17.x86_64 > zlib-1.2.5-7.fc17.x86_64 > (gdb) bt > #0 0x003d54635935 in raise () from /lib64/libc.so.6 > #1 0x003d546370e8 in abort () from /lib64/libc.so.6 > #2 0x003d5462e6a2 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x003d5462e752 in __assert_fail () from /lib64/libc.so.6 > #4 0x7f796eed5823 in transport_consume > (transport=transport@entry=0xc6eb00) at > /home/gordon/projects/proton/proton-c/src/transport/transport.c:1070 > #5 0x7f796eed6e07 in pn_transport_process > (transport=transport@entry=0xc6eb00, size=) at > /home/gordon/projects/proton/proton-c/src/transport/transport.c:2117 > #6 0x7f796eedeb88 in pni_connection_readable (sel=0xc6ea00) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:242 > #7 0x7f796eede310 in pn_messenger_process > (messenger=messenger@entry=0xc6a980) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1354 > #8 0x7f796eede440 in pn_messenger_tsync (timeout=, > predicate=0x7f796eedab00 , messenger=0xc6a980) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1423 > #9 pn_messenger_tsync (messenger=0xc6a980, predicate=0x7f796eedab00 > , timeout=) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1411 > #10 0x7f796eedeca6 in pn_messenger_recv > (messenger=messenger@entry=0xc6a980, n=n@entry=1024) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:2181 > #11 0x00401255 in main (argc=, argv=) > at /home/gordon/projects/proton/examples/messenger/c/recv.c:131 > (gdb) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-988) pn_messenger_set_flags does not support new SASL flag correctly
[ https://issues.apache.org/jira/browse/PROTON-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-988: --- Fix Version/s: (was: 0.10) > pn_messenger_set_flags does not support new SASL flag correctly > --- > > Key: PROTON-988 > URL: https://issues.apache.org/jira/browse/PROTON-988 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 > Environment: All OS >Reporter: Clemens Vasters >Assignee: Andrew Stitcher > Labels: messenger > > The new flag PN_FLAGS_ALLOW_INSECURE_MECHS cannot be set though > pn_messenger_set_flags. > Setting the other defined flag, PN_FLAGS_CHECK_ROUTES, causes the preset > PN_FLAGS_ALLOW_INSECURE_MECHS to be irrecoverably overridden. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-768) DECIMAL32 values are not consistent in Ruby
[ https://issues.apache.org/jira/browse/PROTON-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-768: --- Priority: Minor (was: Major) > DECIMAL32 values are not consistent in Ruby > --- > > Key: PROTON-768 > URL: https://issues.apache.org/jira/browse/PROTON-768 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce >Priority: Minor > > On 32-bit EL6 running Ruby 1.8.7, DECIMAL32 values change. For example, the > following happened during running the rspec tests: > 2) A data object can hold a decimal32 >Failure/Error: expect(@data.decimal32).to eq(value) > > expected: 1161181977 > got: 1536795250 > > (compared using ==) ># ./spec/qpid/proton/data_spec.rb:304 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-759) Provide a non-blocking idiomatic way to sending and receiving messages with Ruby Messenger.
[ https://issues.apache.org/jira/browse/PROTON-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-759: --- Labels: messenger (was: ) > Provide a non-blocking idiomatic way to sending and receiving messages with > Ruby Messenger. > --- > > Key: PROTON-759 > URL: https://issues.apache.org/jira/browse/PROTON-759 > Project: Qpid Proton > Issue Type: New Feature > Components: ruby-binding >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Labels: messenger > > A general pattern in Ruby is to provide a block to systems that perform a > repetitive funtion, such as waiting for input and processing it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-738) Debian + Ubuntu Packages need updating to 0.8
[ https://issues.apache.org/jira/browse/PROTON-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-738. -- Resolution: Fixed Much newer builds are now available in the Qpid released PPA: https://launchpad.net/~qpid/+archive/ubuntu/released > Debian + Ubuntu Packages need updating to 0.8 > - > > Key: PROTON-738 > URL: https://issues.apache.org/jira/browse/PROTON-738 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Dominic Evans >Assignee: Darryl L. Pierce >Priority: Minor > > It would be great if we could get 0.8 packages pushed to the development > releases for debian and ubuntu > https://tracker.debian.org/pkg/qpid-proton > https://launchpad.net/ubuntu/+source/qpid-proton > And debs for the LTS releases pushed to the PPA > https://launchpad.net/~qpid/+archive/ubuntu/released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-530) MessengerImpl.processActive() does not rethrow IOException
[
https://issues.apache.org/jira/browse/PROTON-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-530:
---
Labels: messenger (was: )
> MessengerImpl.processActive() does not rethrow IOException
> --
>
> Key: PROTON-530
> URL: https://issues.apache.org/jira/browse/PROTON-530
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.6
> Environment: JDK 7
>Reporter: Olivier Letellier
> Labels: messenger
>
> Test case :
> A connection has been established successfully from Messenger in Proton-j,
> and the client is waiting (possibly with a timeout) on recv().
> Then the peer resets this connection.
> Effect :
> In MessengerImpl.processActive(), a IOException("Connection reset by peer")
> is raised and catched. Until now everything is fine.
> A log is emitted, but the exception is not re-thrown, not registered, and the
> method continues to process other connections.
> From the client point of view :
> - if recv() has a positive timeout, a TimeoutException is raised, but the
> client cannot discriminate it from a timeout when nothing is received on a
> well established session. My client, for example, re-do a recv() , exits
> immediately with a TimeoutException, and then consumes 100% of the CPU of the
> JVM.
> - if recv() is blocking (negative timeout), an infinite loop is happening
> inside waitUntil(), then consuming 100% of CPU.
> I would suggest to throw a new RuntimeException(IOException) after having
> done the log in the catch clause.
> This problem may be linked to PROTON-525 and PROTON-214.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-731) Installing language bindings provides no means to override the install path
[ https://issues.apache.org/jira/browse/PROTON-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-731: --- Assignee: (was: Darryl L. Pierce) > Installing language bindings provides no means to override the install path > --- > > Key: PROTON-731 > URL: https://issues.apache.org/jira/browse/PROTON-731 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Darryl L. Pierce > Labels: patch > Attachments: > 0001-PROTON-731-Installing-Python-requires-Proton-be-inst.patch > > > When performing an install, such as with Fedora or Ubuntu packaging, the > python installation bits use setuptools to build and install the bindings. > However, since the code isn't necessarily installed at that point the install > fails with: > running sdist > running check > warning: sdist: manifest template 'MANIFEST.in' does not exist (using default > file list) > warning: sdist: standard file not found: should have one of README, README.txt > writing manifest file 'MANIFEST' > creating python-qpid-proton-0.8-0 > making hard links in python-qpid-proton-0.8-0... > hard linking cproton.py -> python-qpid-proton-0.8-0 > hard linking cprotonPYTHON_wrap.c -> python-qpid-proton-0.8-0 > hard linking proton.py -> python-qpid-proton-0.8-0 > hard linking setup.py -> python-qpid-proton-0.8-0 > creating dist > Creating tar archive > removing 'python-qpid-proton-0.8-0' (and everything under it) > running install > running build > running build_py > creating build > creating build/lib.linux-x86_64-2.7 > copying proton.py -> build/lib.linux-x86_64-2.7 > copying cproton.py -> build/lib.linux-x86_64-2.7 > running build_ext > building '_cproton' extension > creating build/temp.linux-x86_64-2.7 > gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv > -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 > -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Itemp/usr/local/include > -I/usr/include/python2.7 -c cprotonPYTHON_wrap.c -o > build/temp.linux-x86_64-2.7/cprotonPYTHON_wrap.o > cprotonPYTHON_wrap.c:3019:24: fatal error: proton/url.h: No such file or > directory > #include > ^ > compilation terminated. > ERROR:root:setup failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
