[jira] [Closed] (PROTON-1157) Reactor sends messages in the clear if ssl is requested but not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1157. --- Released in Qpid Proton 0.12.1, http://qpid.apache.org/releases/qpid-proton-0.12.1/index.html > Reactor sends messages in the clear if ssl is requested but not available. > -- > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.1 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1157) Reactor sends messages in the clear if ssl is requested but not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1157: Summary: Reactor sends messages in the clear if ssl is requested but not available. (was: Reactor sends messages in the clear if ssl is requested by not available.) > Reactor sends messages in the clear if ssl is requested but not available. > -- > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.1 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1157: Fix Version/s: 0.12.1 > Reactor sends messages in the clear if ssl is requested by not available. > - > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.1 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1157: Fix Version/s: (was: 0.13.0) > Reactor sends messages in the clear if ssl is requested by not available. > - > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1157: Assignee: Gordon Sim > Reactor sends messages in the clear if ssl is requested by not available. > - > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.13.0 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1061) [Python Binding] Add support for all AMQP 1.0 types
[ https://issues.apache.org/jira/browse/PROTON-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15177976#comment-15177976 ] Justin Ross commented on PROTON-1061: - [~kpvdr], what's the status of this? > [Python Binding] Add support for all AMQP 1.0 types > --- > > Key: PROTON-1061 > URL: https://issues.apache.org/jira/browse/PROTON-1061 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Currently, a number of AMQP 1.0 simple types are not supported in the Python > binding. Only those types that "make sense" from a Python language > point-of-view are currently supported, but types such as the unsigned > integral types, 32-bit float and the decimal types are not supported. As > long as the Python client only talks to other Python clients, this approach > makes sense, but as soon as a Python client needs to talk to some other > client that may require these types, then an impasse is reached. > The AMQP types currently *NOT* supported in the Python binding are: > * Byte > * Short > * Int (32-bit) > * Ubyte > * Ushort > * Uint (32-bit) > * Float (32-bit) > * Decimal32 > * Decimal64 > * Decimal128 > A proposed patch is available for review at > https://reviews.apache.org/r/39479/. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1138) Assorted C++ API cleanups
Justin Ross created PROTON-1138: --- Summary: Assorted C++ API cleanups Key: PROTON-1138 URL: https://issues.apache.org/jira/browse/PROTON-1138 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.13.0 Reporter: Justin Ross Assignee: Cliff Jansen Fix For: 0.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1138) Assorted C++ API cleanups
[ https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1138: --- Assignee: Justin Ross (was: Cliff Jansen) > Assorted C++ API cleanups > - > > Key: PROTON-1138 > URL: https://issues.apache.org/jira/browse/PROTON-1138 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1134) 0.13.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1134: Fix Version/s: (was: 0.12.0) 0.13.0 > 0.13.0 release tasks > > > Key: PROTON-1134 > URL: https://issues.apache.org/jira/browse/PROTON-1134 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1134) 0.13.0 release tasks
Justin Ross created PROTON-1134: --- Summary: 0.13.0 release tasks Key: PROTON-1134 URL: https://issues.apache.org/jira/browse/PROTON-1134 Project: Qpid Proton Issue Type: Task Components: release Reporter: Justin Ross Assignee: Justin Ross Fix For: 0.12.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-1050) 0.12.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1050. --- Resolution: Fixed Proton 0.12.0 is released. > 0.12.0 release tasks > > > Key: PROTON-1050 > URL: https://issues.apache.org/jira/browse/PROTON-1050 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1099) Upload latest stable release of python-qpid-proton onto pypi
[ https://issues.apache.org/jira/browse/PROTON-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1099: Fix Version/s: (was: 0.12.0) > Upload latest stable release of python-qpid-proton onto pypi > > > Key: PROTON-1099 > URL: https://issues.apache.org/jira/browse/PROTON-1099 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > > A reminder to update Pypi when a new release of proton is available. > I'll move the fix version forward as releases are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1095: Fix Version/s: (was: 0.13.0) > Error handling > -- > > Key: PROTON-1095 > URL: https://issues.apache.org/jira/browse/PROTON-1095 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0 > > > The C++ binding needs a disciplined and effective way to handle protocol (and > transport) errors. > Currently the API has some error events, however if they are not handled the > program will just hang - it would be better in this case to throw an > exception so that the program doesn't just hang. > Another issue is creating error states (attaching a condition) when closing a > connection/session/link - there should be some straightforward way to > indicate the error to your peer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1055) Username sent twice during SASL AUTH
[
https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1055:
Fix Version/s: (was: 0.13.0)
> Username sent twice during SASL AUTH
>
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename: trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.12.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]: -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]: <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]: -> AMQP
> [0x250d3b0]:0 -> @open(16)
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="TEST-queue", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]: <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="",
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000,
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="ActiveMQ", :"topic-prefix"="topic://",
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0,
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]: -> SASL
> [0x18aa060]: <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]: -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs.
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]: -> SASL
> [0xa5d060]: <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
> File "./meow.py", line 12, in
> messenger.send()
> File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568,
> in send
> self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
> 0.08user 0.02system 0:50.69elapsed 0%CPU (0avgtext+0avgdata 12192maxresident)k
> 0inputs+0outputs (0major+5474minor)pagefaults 0swaps
> #
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1123) cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON
[ https://issues.apache.org/jira/browse/PROTON-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1123: Fix Version/s: (was: 0.13.0) > cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON > --- > > Key: PROTON-1123 > URL: https://issues.apache.org/jira/browse/PROTON-1123 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: build-failure > Fix For: 0.12.0 > > > The following syntax error is raised: > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.10") > File "", line 1 > from distutils.sysconfig import get_python_lib; print get_python_lib(True) >^ > SyntaxError: invalid syntax > In python3 print is a function and requires parenthesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1118: Fix Version/s: (was: 0.13.0) > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: build-failure > Fix For: 0.12.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1063) ruby: ruby reactor holds GVL in process
[ https://issues.apache.org/jira/browse/PROTON-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1063: Fix Version/s: (was: 0.12.0) 0.13.0 > ruby: ruby reactor holds GVL in process > --- > > Key: PROTON-1063 > URL: https://issues.apache.org/jira/browse/PROTON-1063 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.10 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.13.0 > > > Ruby has a global lock the GVL, like python's GIL. > The ruby binding Reactor#process blocks in pn_reactor_process while holding > the lock, blocking all other ruby threads. > This is the same issue as PROTON-752, but it was only fixed for messenger, > not for the reactor. > The fix is more complex, we can't simply call pn_reactor_process in > rb_thread_call_without_gvl() because it calls handler functions that call > back into ruby. We need to isolate just the blocking IO code in without_gvl > and restore the lock before handlers call back into ruby. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1127) [Windows] qpid-proton-cpp.dll not installed by "make install" target
[ https://issues.apache.org/jira/browse/PROTON-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134498#comment-15134498 ] Justin Ross commented on PROTON-1127: - Reviewed by Chuck. Approved for 0.12.0. > [Windows] qpid-proton-cpp.dll not installed by "make install" target > > > Key: PROTON-1127 > URL: https://issues.apache.org/jira/browse/PROTON-1127 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 > Environment: Windows MSVC >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1121) Zero pointer derefence in pn_sasl_allowed_mechs()
[ https://issues.apache.org/jira/browse/PROTON-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129163#comment-15129163 ] Justin Ross commented on PROTON-1121: - Reviewed by Ken. Approved for 0.12.0. > Zero pointer derefence in pn_sasl_allowed_mechs() > - > > Key: PROTON-1121 > URL: https://issues.apache.org/jira/browse/PROTON-1121 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: coverity, crash > Fix For: 0.13.0 > > > Coverity detected a potential derefence of a null string pointer in > pn_sasl_allowed_mechs(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1116) Potential infinite recursion detected by VC++14 compiler
[
https://issues.apache.org/jira/browse/PROTON-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129160#comment-15129160
]
Justin Ross commented on PROTON-1116:
-
Reviewed by Andrew. Approved for 0.12.0.
> Potential infinite recursion detected by VC++14 compiler
>
>
> Key: PROTON-1116
> URL: https://issues.apache.org/jira/browse/PROTON-1116
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.12.0
> Environment: Visual Studio 2015 Update 1, Visual Studio 2010
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>Priority: Blocker
>
> I get the following warning when running the Visual Studio 2015 compiler on
> the C++ binding code
> {noformat}
> 29>c:\users\andrew\documents\github\qpid-proton\proton-c\bindings\cpp\include\proton\value.hpp(49):
> warning C4717:
> 'proton::value::value >,proton::value> >': recursive on all control paths, function will cause
> runtime stack overflow
> {noformat}
> My guess is that we never actually try to run this code in the tests or e
> would indeed by seeing a failure, however I think we must eliminate this as a
> bug before releasing 0.12.
> Either remove the code so removing the warning (as the code seems like it
> can't have been called in testing) or fix the code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1125) c++: core dump on empty address in link options
[ https://issues.apache.org/jira/browse/PROTON-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129657#comment-15129657 ] Justin Ross commented on PROTON-1125: - Reviewed by me. Approved for 0.12.0. > c++: core dump on empty address in link options > --- > > Key: PROTON-1125 > URL: https://issues.apache.org/jira/browse/PROTON-1125 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.1 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.12.0 > > > See: > https://scan4.coverity.com/reports.htm#v14284/p10556/fileInstanceId=8369775=1901068=122279=1901068-29 > This is just the core dump on empty address fix from proton-1122, separated > for 0,12 release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1050) 0.12.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129684#comment-15129684 ] Justin Ross commented on PROTON-1050: - That should read 0.12.0 beta! > 0.12.0 release tasks > > > Key: PROTON-1050 > URL: https://issues.apache.org/jira/browse/PROTON-1050 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1121) Zero pointer derefence in pn_sasl_allowed_mechs()
[ https://issues.apache.org/jira/browse/PROTON-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1121: Labels: coverity crash (was: coverity) > Zero pointer derefence in pn_sasl_allowed_mechs() > - > > Key: PROTON-1121 > URL: https://issues.apache.org/jira/browse/PROTON-1121 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: coverity, crash > > Coverity detected a potential derefence of a null string pointer in > pn_sasl_allowed_mechs(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1120) Memory leak using proton.utils
[
https://issues.apache.org/jira/browse/PROTON-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127679#comment-15127679
]
Justin Ross commented on PROTON-1120:
-
Reviewed by Ken. Approved for 0.12.0.
> Memory leak using proton.utils
> --
>
> Key: PROTON-1120
> URL: https://issues.apache.org/jira/browse/PROTON-1120
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Environment: python-qpid-proton-0.10-2.fc23.x86_64
> And 0.9-13
>Reporter: Jeff Ortel
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
> Attachments: memory-leak.py
>
>
> I have observed a fairly substantial memory leak using the blocking classes
> in proton.utils. Mainly with sending messages.
> Observations:
> {code}
> growth = 52 MB for 10,000 messages sent
> growth = 104 MB for 20,000 messages sent
> leak = 52 MB per 10,000 sends or ~5 kB / send
> {code}
> The attached reproducer, can be used to collect and display statistics.
> There is likely a better method for measuring the memory growth but this was
> easy. Perhaps there is something incorrect/missing with the way I'm using
> proton or measuring the memory growth/leak?
> {code}
>
> 1 messages
>
> total kB 242088 162567552 - sending
> total kB 293980 68224 59520 - sent
> total kB 293980 68228 59524 - receiving
> total kB 294236 68340 59632 - received
> SizeGrowth Context
> __||__
> 242088 kB +242088 kB sending
> 293980 kB + 51892 kB sent
> 293980 kB + 0 kB receiving
> 294236 kB + 256 kB received
>
> 2 messages
>
> total kB 294236 68348 59640 - sending
> total kB 397820 171896 163232 - sent
> total kB 397820 171900 163236 - receiving
> total kB 398020 172060 163396 - received
> SizeGrowth Context
> __||__
> 294236 kB +294236 kB sending
> 397820 kB +103584 kB sent
> 397820 kB + 0 kB receiving
> 398020 kB + 200 kB received
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126726#comment-15126726 ] Justin Ross commented on PROTON-1118: - Reviewed by Andrew. Approved for 0.12.0. > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: build-failure > Fix For: 0.13.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- 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: (was: 0.12.0) 0.13.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.13.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] [Commented] (PROTON-1114) [proton-j] the transport should not emit other frames after the Close frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123814#comment-15123814 ] Justin Ross commented on PROTON-1114: - Reviewed by Andrew. Approved for 0.12.0. > [proton-j] the transport should not emit other frames after the Close frame > has been sent > - > > Key: PROTON-1114 > URL: https://issues.apache.org/jira/browse/PROTON-1114 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The proton-j transport can emit other frames after sending the Close frame > [whether because the Connection object was closed explicitly, or otherwise], > which is forbidden by the AMQP spec and as such needs to be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1113) tidy up some descriptive detail around running the python tests
[ https://issues.apache.org/jira/browse/PROTON-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123818#comment-15123818 ] Justin Ross commented on PROTON-1113: - Reviewed by Andrew. Approved for 0.12.0. > tidy up some descriptive detail around running the python tests > --- > > Key: PROTON-1113 > URL: https://issues.apache.org/jira/browse/PROTON-1113 > Project: Qpid Proton > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH
[
https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121670#comment-15121670
]
Justin Ross commented on PROTON-1055:
-
Reviewed by Robbie. Approved for 0.12.0.
> Username sent twice during SASL AUTH
>
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename: trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]: -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]: <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]: -> AMQP
> [0x250d3b0]:0 -> @open(16)
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="TEST-queue", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]: <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="",
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000,
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="ActiveMQ", :"topic-prefix"="topic://",
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0,
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]: -> SASL
> [0x18aa060]: <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]: -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs.
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]: -> SASL
> [0xa5d060]: <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
> File "./meow.py", line 12, in
> messenger.send()
> File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568,
> in send
> self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
> 0.08user 0.02system 0:50.69elapsed 0%CPU (0avgtext+0avgdata 12192maxresident)k
> 0inputs+0outputs (0major+5474minor)pagefaults 0swaps
> #
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121855#comment-15121855 ] Justin Ross commented on PROTON-1095: - I don't get it. This change looks like it's beyond what Andrew's change would require. Proton is in Beta. This looks like you're bringing in the newest API thinking. > Error handling > -- > > Key: PROTON-1095 > URL: https://issues.apache.org/jira/browse/PROTON-1095 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0, 0.13.0 > > > The C++ binding needs a disciplined and effective way to handle protocol (and > transport) errors. > Currently the API has some error events, however if they are not handled the > program will just hang - it would be better in this case to throw an > exception so that the program doesn't just hang. > Another issue is creating error states (attaching a condition) when closing a > connection/session/link - there should be some straightforward way to > indicate the error to your peer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120712#comment-15120712 ] Justin Ross commented on PROTON-1095: - The additional commits are required to avoid a test hang (and make the error handling behave as intended). Reviewed by Alan. Approved for 0.12.0. > Error handling > -- > > Key: PROTON-1095 > URL: https://issues.apache.org/jira/browse/PROTON-1095 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0, 0.13.0 > > > The C++ binding needs a disciplined and effective way to handle protocol (and > transport) errors. > Currently the API has some error events, however if they are not handled the > program will just hang - it would be better in this case to throw an > exception so that the program doesn't just hang. > Another issue is creating error states (attaching a condition) when closing a > connection/session/link - there should be some straightforward way to > indicate the error to your peer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15119806#comment-15119806 ] Justin Ross commented on PROTON-: - Correction, epydoc, not sphinx. > Fix warnings during make doc > > > Key: PROTON- > URL: https://issues.apache.org/jira/browse/PROTON- > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15119796#comment-15119796 ] Justin Ross commented on PROTON-: - No, it's simply because sphinx doesn't understand (warns on) from . import. > Fix warnings during make doc > > > Key: PROTON- > URL: https://issues.apache.org/jira/browse/PROTON- > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1111) Fix warnings during make doc
Justin Ross created PROTON-: --- Summary: Fix warnings during make doc Key: PROTON- URL: https://issues.apache.org/jira/browse/PROTON- Project: Qpid Proton Issue Type: Improvement Components: proton-c, python-binding Affects Versions: 0.13.0 Reporter: Justin Ross Assignee: Justin Ross Priority: Minor Fix For: 0.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-. - Resolution: Fixed > Fix warnings during make doc > > > Key: PROTON- > URL: https://issues.apache.org/jira/browse/PROTON- > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15117247#comment-15117247 ] Justin Ross commented on PROTON-1100: - The last commit arrived just before the beta was created. Approved for 0.12.0. > [proton-j] the transport should not emit other frames before the Open frame > has been sent > - > > Key: PROTON-1100 > URL: https://issues.apache.org/jira/browse/PROTON-1100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > As per PROTON-1070 description, the proton-j transport can emit other frames > without first sending the Open frame [because the Connection object wasnt > actually opened], which is erroneous behaviour and should be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1109) Improve the C++ binding documentation
Justin Ross created PROTON-1109: --- Summary: Improve the C++ binding documentation Key: PROTON-1109 URL: https://issues.apache.org/jira/browse/PROTON-1109 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Justin Ross Assignee: Justin Ross Fix For: 0.12.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106717#comment-15106717 ] Justin Ross commented on PROTON-1088: - I don't think the patch on this one is ready. The names of the constants and methods differ. The number of new methods in Python is large, and it's not clear to me why we need this many convenience accessors. Many of these no-arg accessors are named get_something, where the Proton style is to use property accessors without get_. Indeed the patch itself does this in one instance, but not others. IMO, since this is public API and not just an implementation detail, this hasn't received enough attention to go in for 0.12.0 at this point. > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- 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 messenger (was: message) > 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, messenger > > 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-241) proton-c: mark old transport interfaces 'deprecated'
[
https://issues.apache.org/jira/browse/PROTON-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-241:
---
Labels: api (was: visibility)
> proton-c: mark old transport interfaces 'deprecated'
>
>
> Key: PROTON-241
> URL: https://issues.apache.org/jira/browse/PROTON-241
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ken Giusti
>Priority: Trivial
> Labels: api
>
> Once PROTON-225 is implemented, we should eventually remove the old
> interfaces after marking them deprecated.
> Example:
> #ifdef __GNUC__
> #define DEPRECATED(func) func __attribute__ ((deprecated))
> #elif defined(_MSC_VER)
> #define DEPRECATED(func) __declspec(deprecated) func
> #else
> #pragma message("WARNING: You need to implement DEPRECATED for this compiler")
> #define DEPRECATED(func) func
> #endif
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-236: --- Labels: windows (was: ) > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: windows > Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-335) Need a means of specifying and reading link properties
[ https://issues.apache.org/jira/browse/PROTON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-335: --- Labels: api (was: ) > Need a means of specifying and reading link properties > -- > > Key: PROTON-335 > URL: https://issues.apache.org/jira/browse/PROTON-335 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Priority: Minor > Labels: api > > There are some cases where it may be beneficial to use link properties (since > link capabilities do not allow for key-value pairs, they can't easily convey > a desired configurable value and the properties on a terminus refer to the > dynamically created node not the link or the terminus itself). > (I've set this to minor since major feels a little strong, but I do think its > important ultimately for the engine to expose all the extension points from > the protocol.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-330) Centos 6.4 build failure: Could NOT find Java
[ https://issues.apache.org/jira/browse/PROTON-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-330. -- Resolution: Fixed https://github.com/apache/qpid-proton/blob/master/INSTALL.md The install instructions now reference the openjdk-devel package. > Centos 6.4 build failure: Could NOT find Java > - > > Key: PROTON-330 > URL: https://issues.apache.org/jira/browse/PROTON-330 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.4 > Environment: Centos 6.4 x86_64 >Reporter: Evgeny Minkevich >Priority: Minor > > [tcs@centos build]$ echo $M2_HOME > /home/tcs/apache-maven-3.0.5 > [tcs@centos build]$ echo $JAVA_HOME > /usr/lib/jvm/jre-1.6.0-openjdk.x86_64 > [tcs@centos build]$ cmake -DCMAKE_INSTALL_PREFIX=/usr .. > PN_VERSION: 0.4 > -- Could NOT find Java (missing: Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE > Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE) > -- Cannot find both Java and Maven: testing disabled for Proton-J and JNI > Bindings -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-363) recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error 11004
[ https://issues.apache.org/jira/browse/PROTON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-363: --- Labels: windows (was: ) > recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error > 11004 > - > > Key: PROTON-363 > URL: https://issues.apache.org/jira/browse/PROTON-363 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Windows XP, Visual Studio 2010 >Reporter: Jakub Scholz > Labels: windows > > I build the proton-c library on Windows XP using Visual Studio 10. > Afterwards, when trying to run the recv.exe and send.exe examples, the > recv.exe always fails with: > > recv.exe amqp://~0.0.0.0:5672 > getnameinfo: The requested name is valid and was found in the database, but > it does not have the correct associated data being resolved for. > It doesn't fail immediately after start but only when I attempt to connect > with send.exe. As a result, the Proton seems to be pretty much not working on > my machine. > --- > The error seems to originate from the function pn_listener_accept in driver.c > and it translates to WSANO_DATA error / error 11004. I did some digging > around and playing with the getnameinfo function and it seems to me, that the > problem is that the getnameinfo function is unable to recognize the service > name based on the port number. And - according to MSDN > (http://msdn.microsoft.com/en-us/library/windows/desktop/ms738532(v=vs.85).aspx) > - that on Windows Server 2003 and earlier results in error (on Windows Vista > and later this works fine). > If I add a flag NI_NUMERICSERV to the getnameinfo call: > code = getnameinfo((struct sockaddr *) , addrlen, host, 1024, serv, 64, > NI_NUMERICSERV) > it will not return an error but return success and use the port number as a > service name. And with this change the recv.exe starts working fine. > However, adding this flag will on Windows Vista and higher and in Linux > probably result in the service name being always returned as a port number > and not as a name. So I'm not sure it is desired to add this flag on all > platforms. > Regards > Jakub -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler
[ https://issues.apache.org/jira/browse/PROTON-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-21: -- Labels: api patch (was: api) > Extract the logical AMQP frame handling to an AbstractConnectionHandler > --- > > Key: PROTON-21 > URL: https://issues.apache.org/jira/browse/PROTON-21 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Hiram Chirino >Assignee: Rob Godfrey > Labels: api, patch > Attachments: PROTON-21-v3.patch > > > Right now all the logic that handles logical AMQP frame events is inside of > the TransportImpl class. That interface only allows you to pump bytes in and > out of the connection. If we extract all the handling logic to an > AbstractConnectionHandler you should be able to use that directly and pump > logical AMQP frames and avoid the frame encoding/decoding phase that the > TransportImpl also does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-73) Server should force renegotiate when client authentication setting is changed on an active connection.
[ https://issues.apache.org/jira/browse/PROTON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-73: -- Labels: security ssl (was: ssl) > Server should force renegotiate when client authentication setting is changed > on an active connection. > -- > > Key: PROTON-73 > URL: https://issues.apache.org/jira/browse/PROTON-73 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Labels: security, ssl > > If the server application changes the peer authentication setting from > 'anonymous' to 'verify-peer' while an SSL session is active, then the server > should force the client to re-negotiate (SSL handshake) to verify the > remote's identity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-291) fix the SSL layer of the transport to only pop from the amqp layer when bytes are known to have actually been written to the socket
[ https://issues.apache.org/jira/browse/PROTON-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-291: --- Labels: ssl (was: ) > fix the SSL layer of the transport to only pop from the amqp layer when bytes > are known to have actually been written to the socket > --- > > Key: PROTON-291 > URL: https://issues.apache.org/jira/browse/PROTON-291 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rafael H. Schloming >Assignee: Ken Giusti > Labels: ssl > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-303) Need an easy to use Map handling API
[ https://issues.apache.org/jira/browse/PROTON-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-303: --- Labels: codec (was: ) > Need an easy to use Map handling API > > > Key: PROTON-303 > URL: https://issues.apache.org/jira/browse/PROTON-303 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Priority: Minor > Labels: codec > > Using the exiting data and codec apis for manipulating maps are a pain. As a > convenience, a set of higher level map utilities should be provided by proton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault
[ https://issues.apache.org/jira/browse/PROTON-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-158: --- Labels: crash (was: ) > detach with invalid handle causes segfault > -- > > Key: PROTON-158 > URL: https://issues.apache.org/jira/browse/PROTON-158 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Minor > Labels: crash > > I.e. a detach where the handle was not previously used in an attach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-357) Add PHP PECL package
[ https://issues.apache.org/jira/browse/PROTON-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-357: --- Labels: packaging (was: ) > Add PHP PECL package > > > Key: PROTON-357 > URL: https://issues.apache.org/jira/browse/PROTON-357 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.4 > Environment: Linux, Macos X >Reporter: Serge Smertin > Labels: packaging > > In order to get Proton adoption in PHP ecosystem and not to build library > from sources, PECL package should be introduced. Probably with Packagist as > well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-254) Swig generated c code for java bindings fails to compile on Windows Visual Studio 2010
[ https://issues.apache.org/jira/browse/PROTON-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-254: --- Labels: patch windows (was: windows) > Swig generated c code for java bindings fails to compile on Windows Visual > Studio 2010 > -- > > Key: PROTON-254 > URL: https://issues.apache.org/jira/browse/PROTON-254 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows 7 > Visual Studio 2010 >Reporter: Keith Wall >Assignee: Cliff Jansen > Labels: patch, windows > Attachments: > 0001-PROTON-254-Resolve-Nested-union-not-currently-suppor.patch, > make-proton-jni-cxx-errors.txt, pn254-cj-0.patch > > > Swig generated C code for the Java bindings fails to compile on Visual Studio > 2010 with error message: > C1083: Cannot open include file: 'stdbool.h': No such file or directory > After discussion on list [1], we tried changing bindings/java/CMakeLists.txt > to use CPLUSPLUS ON directive to CMake in the case where BUILD_WITH_CXX has > been enabled earlier in the build. > if (BUILD_WITH_CXX) >SET_SOURCE_FILES_PROPERTIES(java.i PROPERTIES CPLUSPLUS ON) > endif (BUILD_WITH_CXX) > Switching to CPP in this way exposed a number of errors when compiling the > CPP code resulting from the java.i (casting issues, pointer arithmetic etc - > see attached make-proton-jni-cxx-errors.txt). However, even after resolving > the CPP compilation issues, we then encounter a problem with Swig's handling > of nested unions when when CPP. The seeming inability of SWIG (when used > with CPP) to represent the union means that SWIG does not produce > pn_atom_t_u.java. JNIMessage.java, which references pn_atom_t_u, > consequently fails to compile. > The warning from swig is: > /home/keith/src/proton/proton-c/include/proton/codec.h:91: Warning 312: > Nested union not currently supported (ignored). > > [1] > http://mail-archives.apache.org/mod_mbox/qpid-proton/201302.mbox/%3ccamyv19mgbdvd2wextvpwywtysskadokb7wtj+u-3jkncwdx...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-326) proton-c ServerTest.testIdleTimeout sometimes fails, causing test suite to hang forever
[
https://issues.apache.org/jira/browse/PROTON-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed PROTON-326.
--
Resolution: Unresolved
Closing this on the idea that it's probably out of date. Please reopen if I am
wrong.
> proton-c ServerTest.testIdleTimeout sometimes fails, causing test suite to
> hang forever
> ---
>
> Key: PROTON-326
> URL: https://issues.apache.org/jira/browse/PROTON-326
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.4
> Environment: Linux
>Reporter: Philip Harvey
>
> I ran the python test suite against proton-c today and noticed that
> ServerTest.testIdleTimeout failed with the following output:
> {noformat}
> proton_tests.engine.ServerTest.testIdleTimeout
> ..ERROR amqp:resource-limit-exceeded
> local-idle-timeout expired
> fail
> Error during test: Traceback (most recent call last):
> File "./tests/python/proton-test", line 340, in run
> phase()
> File "/.../workspace/proton/tests/python/proton_tests/engine.py", line
> 1412, in testIdleTimeout
> assert self.conn.state == (Endpoint.LOCAL_ACTIVE |
> Endpoint.REMOTE_ACTIVE), "Connection terminated"
> AssertionError: Connection terminated
> {noformat}
> This test usually succeeds so I guess it contains a race condition.
> Something that is arguably more problematic is that this failure causes the
> test suite to hang. The suite proceeds to run the other tests, but does not
> terminate when it reaches the end. On Linux, I actually had to kill the
> process rather than ctrl-c-ing it.
> I cannot reproduce the test failure, but I do find that if I make it fail
> (for example, by modifying the assert on line 1412 to always fail) then the
> suite hangs every time.
> It's obviously undesirable for a failing test to cause the entire suite to
> hang.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-327) proton-c: soak.MessengerTests.test_relay_C_SSL sometimes fails
[ https://issues.apache.org/jira/browse/PROTON-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-327. -- Resolution: Unresolved An old test failure that is probably out of date. Please reopen if it makes sense to. > proton-c: soak.MessengerTests.test_relay_C_SSL sometimes fails > -- > > Key: PROTON-327 > URL: https://issues.apache.org/jira/browse/PROTON-327 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Linux >Reporter: Philip Harvey > > Today I observed the following test failure on my CI server. This is the > first time I've seen the test fail. It passed when I re-ran it. > Here is the test output: > proton_tests.soak.MessengerTests.test_relay_C_SSL (from pythontests) > Failing for the past 1 build (Since Failed#122 ) > Took 1 min 0 sec. > add description > Error Message > Command '['msgr-send', '-a', > 'amqps://0.0.0.0:58694/X0Y,amqps://0.0.0.0:58694/X1Y,amqps://0.0.0.0:58694/X2Y,amqps://0.0.0.0:58694/X3Y,amqps://0.0.0.0:58694/X4Y', > '-c', '85', '-R', '-t', '60']' failed > Stacktrace > Error during test: Traceback (most recent call last): > File "./tests/python/proton-test", line 340, in run > phase() > File "/.../proton/tests/python/proton_tests/soak.py", line 310, in > test_relay_C_SSL > self._do_relay_test(MessengerReceiverC(), MessengerReceiverC(), > MessengerSenderC(), "amqps") > File "/.../proton/tests/python/proton_tests/soak.py", line 220, in > _do_relay_test > self._do_test(iterations) > File "/.../proton/tests/python/proton_tests/soak.py", line 96, in _do_test > assert S.status() == 0, "Command '%s' failed" % str(S.cmdline()) > AssertionError: Command '['msgr-send', '-a', > 'amqps://0.0.0.0:58694/X0Y,amqps://0.0.0.0:58694/X1Y,amqps://0.0.0.0:58694/X2Y,amqps://0.0.0.0:58694/X3Y,amqps://0.0.0.0:58694/X4Y', > '-c', '85', '-R', '-t', '60']' failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-241) proton-c: mark old transport interfaces 'deprecated'
[
https://issues.apache.org/jira/browse/PROTON-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-241:
---
Labels: visibility (was: )
> proton-c: mark old transport interfaces 'deprecated'
>
>
> Key: PROTON-241
> URL: https://issues.apache.org/jira/browse/PROTON-241
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ken Giusti
>Priority: Trivial
> Labels: visibility
>
> Once PROTON-225 is implemented, we should eventually remove the old
> interfaces after marking them deprecated.
> Example:
> #ifdef __GNUC__
> #define DEPRECATED(func) func __attribute__ ((deprecated))
> #elif defined(_MSC_VER)
> #define DEPRECATED(func) __declspec(deprecated) func
> #else
> #pragma message("WARNING: You need to implement DEPRECATED for this compiler")
> #define DEPRECATED(func) func
> #endif
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-186: --- Labels: patch (was: ) > Message encode should always return the number of bytes needed to fully > encode the message > -- > > Key: PROTON-186 > URL: https://issues.apache.org/jira/browse/PROTON-186 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Hiram Chirino > Labels: patch > Attachments: PROTON-186v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-151) Have the python interface use dynamic proxies to the engine impl objects so to ensure that only public interface methods are being used by the python tests.
[ https://issues.apache.org/jira/browse/PROTON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-151: --- Labels: patch (was: ) > Have the python interface use dynamic proxies to the engine impl objects so > to ensure that only public interface methods are being used by the python > tests. > > > Key: PROTON-151 > URL: https://issues.apache.org/jira/browse/PROTON-151 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > Labels: patch > Attachments: PROTON-151.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-162) SSL implementation does not support certification revocation
[ https://issues.apache.org/jira/browse/PROTON-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-162: --- Labels: security ssl (was: ) > SSL implementation does not support certification revocation > > > Key: PROTON-162 > URL: https://issues.apache.org/jira/browse/PROTON-162 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 >Reporter: Ken Giusti > Labels: security, ssl > > OpenSSL supports a means for configuring lists of revoked certificates. The > SSL layer used by proton-c does not provide a means to configure this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-237) Porting Issue -- basename() not found in Visual Studio 2010
[
https://issues.apache.org/jira/browse/PROTON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-237:
---
Labels: build windows (was: build)
> Porting Issue -- basename() not found in Visual Studio 2010
> ---
>
> Key: PROTON-237
> URL: https://issues.apache.org/jira/browse/PROTON-237
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows Visual Studio 2010
>Reporter: Mary hinton
> Labels: build, windows
>
> The basename() function in proton.c is not found in Visual Studio 2010. It is
> in Visual Studio 2012 when the header is included.
> It is only used in a printf statement and is not needed for porting to Visual
> Studio 2010:
> printf("Usage: %s [-h] [-c [user[:password]@]host[:port]] [-a ] [-m
> ]\n", basename(argv[0]));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-542) Message.properties should default to an empty dictionary
[ https://issues.apache.org/jira/browse/PROTON-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-542. -- Resolution: Won't Fix > Message.properties should default to an empty dictionary > > > Key: PROTON-542 > URL: https://issues.apache.org/jira/browse/PROTON-542 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.7 >Reporter: Justin Ross > > Message.properties should default to an empty dictionary, not null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-999) Docs: pn_messenger_subscribe(): "source" is undocumented
[ https://issues.apache.org/jira/browse/PROTON-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-999: --- Labels: documentation messenger (was: documentation) > Docs: pn_messenger_subscribe(): "source" is undocumented > > > Key: PROTON-999 > URL: https://issues.apache.org/jira/browse/PROTON-999 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Graham Leggett >Assignee: Justin Ross > Labels: documentation, messenger > > The pn_messenger_subscribe() function is documented to take a const char * as > a "source": > https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6 > The definition of a "source" isn't specified, nor is the acceptable source > format specified. > In addition, it isn't specified in the docs whether this function must be > called once, or whether it can be called multiple times. Reverse engineering > the source seems to indicate that it should be called just once, and if you > call it multiple times the underlying event loop will be corrupted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-260) Messenger Documentation
[ https://issues.apache.org/jira/browse/PROTON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-260: --- Labels: messenger (was: ) > Messenger Documentation > --- > > Key: PROTON-260 > URL: https://issues.apache.org/jira/browse/PROTON-260 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.5 >Reporter: michael goulish >Assignee: michael goulish > Labels: messenger > > Write documentation for the Proton Messenger interface, to include: > introduction > API explanations > theory of operation > example programs > programming idioms > tutorials > quickstarts > troubleshooting > Documents should use MarkDown markup language. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-574: --- Labels: messenger patch (was: ) > proton-c: Messenger doesn't indicate when connection is aborted for a SASL > negotation failure > - > > Key: PROTON-574 > URL: https://issues.apache.org/jira/browse/PROTON-574 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Dominic Evans >Assignee: Andrew Stitcher > Labels: messenger, patch > Attachments: 05_return_sasl_auth_errors_messenger.c.patch, > 05_return_sasl_auth_errors_transport.c.patch, > 05_return_sasl_auth_errors_transport.h.patch > > > Currently if a Messenger's connection is aborted at the remote end, there's > no differentiation between the connection just being dropped and a failure to > negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-441) Provide hooks for alternative sources of Messenger routes
[ https://issues.apache.org/jira/browse/PROTON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-441. -- Resolution: Won't Fix > Provide hooks for alternative sources of Messenger routes > - > > Key: PROTON-441 > URL: https://issues.apache.org/jira/browse/PROTON-441 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.5 >Reporter: Ted Ross > Labels: messenger > > This is a request to add the capability to set Messenger routes automatically > on Messenger startup. Where the routes come from may be platform-specific > (i.e. environment variables, configuration files, registries, network-based > lookup, etc.). > The desire is to allow Messenger applications to be wholly unaware of the > route mappings that come from other sources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1041) Add recurring timer example to the reactive C++ documentation
[ https://issues.apache.org/jira/browse/PROTON-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1041: Fix Version/s: 0.12.0 > Add recurring timer example to the reactive C++ documentation > - > > Key: PROTON-1041 > URL: https://issues.apache.org/jira/browse/PROTON-1041 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0, 0.12.0 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Labels: patch > Fix For: 0.12.0 > > Attachments: recurring-timer-example.patch > > > The C++ documentation is missing the recurring_timer.cpp example in its > documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-544) Subscriptions have no documentation
[
https://issues.apache.org/jira/browse/PROTON-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-544:
---
Labels: messenger (was: )
> Subscriptions have no documentation
> ---
>
> Key: PROTON-544
> URL: https://issues.apache.org/jira/browse/PROTON-544
> Project: Qpid Proton
> Issue Type: Improvement
> Components: python-binding
>Affects Versions: 0.7
>Reporter: Justin Ross
> Labels: messenger
>
> For instance, you really want to know that when you do this:
> sub = msgr.subscribe("amqp://0.0.0.0/#")
> You have sub.address, so you can do this:
> msg = Message()
> msg.reply_to = sub.address
> The API doc for Messenger.subscribe says nothing about its return value, and
> Subscription is not among the classes in the generated API doc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-614) PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]: no valid sources'
[
https://issues.apache.org/jira/browse/PROTON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-614:
---
Labels: messenger php php-proton (was: php php-proton)
> PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]:
> no valid sources'
> ---
>
> Key: PROTON-614
> URL: https://issues.apache.org/jira/browse/PROTON-614
> Project: Qpid Proton
> Issue Type: Bug
> Components: php-binding
>Affects Versions: 0.7
> Environment: Ubuntu Linux on Amazon EC2
>Reporter: Jose Berardo Cunha
>Priority: Minor
> Labels: messenger, php, php-proton
>
> Sorry, but I don't know if it is really a bug or I'm doing something wrong.
> There is no documentation for Proton PHP, so here I am.
> Every time I try to execute recv.php sample I get this error:
> [0x16d2180]:ERROR[0] (null)
> [0x16d2180]:ERROR[0] (null)
> CONNECTION ERROR connection aborted (remote)
> PHP Fatal error: Uncaught exception 'MessengerException' with message '[-5]:
> no valid sources' in /usr/share/php/proton.php:61
> Stack trace:
> #0 /usr/share/php/proton.php(146): Messenger->_check(-5)
> #1 /home/ubuntu/qpid-proton-0.7/tests/smoke/recv.php(20): Messenger->recv()
> #2 {main}
> thrown in /usr/share/php/proton.php on line 61
> I've tried all of this command lines:
> $ php recv.php
> $ php recv.php "amqp://0.0.0.0"
> $ php recv.php "amqp://127.0.0.1"
> $ php recv.php "amqp://localhost"
> $ php recv.php "amqp://localhost:5672"
> $ php recv.php "amqp://localhost/myqueue"
> $ php recv.php "amqp://localhost:5672/myqueue"
> Where myqueue is my first queue created at Qpid 0.28 Web Console.
> I'got the same Connection aborted on send.php but what is weird is when I run
> send.php against an ActiveMQ Apollo broker I have no error message and I can
> see for just one or two seconds one line referring my message sent to it at
> its web console. So I presumed that send.php is able to connect an amqp
> broker but I don't know why it doesn't connect to Qpid 0.28.
> Please, What am I doing wrong, what are valid sources and where can I find
> more documentation about the Proton PHP library?
> Even the proton.php and cproton.php created by Swig have no comments.
> Thank you.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-886) make proton enforce handle-max
[ https://issues.apache.org/jira/browse/PROTON-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-886: --- Component/s: proton-j proton-c > make proton enforce handle-max > --- > > Key: PROTON-886 > URL: https://issues.apache.org/jira/browse/PROTON-886 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Reporter: michael goulish > > Make the code enforce limits on handles (and links) from section 2.7.2 of the > AMQP 1.0 spec. > The handle-max value is the highest handle value that can be used on the > session. A peer MUST NOT attempt to attach a link using a handle value > outside the range that its partner can handle. A peer that receives a handle > outside the supported range MUST close the connection with the framing-error > error-code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1057) Windows SChannel SSL test failure
[ https://issues.apache.org/jira/browse/PROTON-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1057: Labels: windows (was: ) > Windows SChannel SSL test failure > - > > Key: PROTON-1057 > URL: https://issues.apache.org/jira/browse/PROTON-1057 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 > Environment: Windows only. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > > This problem started since PROTON-1048 which did not touch the Proton-C > SChannel related code - it just tweaked the test infrastructure to use > alternate certificate formats for Windows. > The proton_tests.ssl.SslTest.test_server_hostname_authentication test > randomly crashes on Windows, presumably from some memory corruption > somewhere. It often runs fine. Seems to happen more frequently on some > systems than others. Not yet seen on a 64 bit build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-470) Perl bindings should have an interop test
[ https://issues.apache.org/jira/browse/PROTON-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-470: --- Assignee: (was: Darryl L. Pierce) > Perl bindings should have an interop test > - > > Key: PROTON-470 > URL: https://issues.apache.org/jira/browse/PROTON-470 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Darryl L. Pierce > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-342: --- Assignee: (was: Darryl L. Pierce) > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-451) PHP binding build failed with PHP5.5 (ZTS)
[ https://issues.apache.org/jira/browse/PROTON-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-451: --- Assignee: (was: Darryl L. Pierce) > PHP binding build failed with PHP5.5 (ZTS) > -- > > Key: PROTON-451 > URL: https://issues.apache.org/jira/browse/PROTON-451 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Debian 7 (amd64), PHP5.5.5 (built from source) >Reporter: Dmitrii Zolotov > > SWIG PHP binding compilation failed with following errors: > In file included from /usr/include/php/Zend/zend_alloc.h:27:0, > from /usr/include/php/Zend/zend.h:252, > from php_wrap.c:706: > php_wrap.c: In function ‘t_output_helper’: > /usr/include/php/Zend/../TSRM/TSRM.h:167:18: error: ‘tsrm_ls’ undeclared > (first use in this function) > #define TSRMLS_C tsrm_ls > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:168:21: note: in expansion of macro > ‘TSRMLS_C’ > #define TSRMLS_CC , TSRMLS_C > ^ > /usr/include/php/Zend/zend_gc.h:160:32: note: in expansion of macro > ‘TSRMLS_CC’ >gc_remove_zval_from_buffer(z TSRMLS_CC); \ > ^ > /usr/include/php/Zend/zend_gc.h:213:6: note: in expansion of macro > ‘GC_REMOVE_ZVAL_FROM_BUFFER’ > GC_REMOVE_ZVAL_FROM_BUFFER(z); \ > ^ > php_wrap.c:1154:5: note: in expansion of macro ‘FREE_ZVAL’ > FREE_ZVAL(o); > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:167:18: note: each undeclared identifier > is reported only once for each function it appears in > #define TSRMLS_C tsrm_ls > ^ > /usr/include/php/Zend/../TSRM/TSRM.h:168:21: note: in expansion of macro > ‘TSRMLS_C’ > #define TSRMLS_CC , TSRMLS_C > ^ > /usr/include/php/Zend/zend_gc.h:160:32: note: in expansion of macro > ‘TSRMLS_CC’ >gc_remove_zval_from_buffer(z TSRMLS_CC); \ > ^ > /usr/include/php/Zend/zend_gc.h:213:6: note: in expansion of macro > ‘GC_REMOVE_ZVAL_FROM_BUFFER’ > GC_REMOVE_ZVAL_FROM_BUFFER(z); \ > ^ > php_wrap.c:1154:5: note: in expansion of macro ‘FREE_ZVAL’ > FREE_ZVAL(o); > ^ > I've tried to run swig manually (with php.i / cproton.i) and get the same > error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-437) Cmake fails to find Perl libraries on Ubuntu 11.10
[ https://issues.apache.org/jira/browse/PROTON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-437: --- Assignee: (was: Darryl L. Pierce) > Cmake fails to find Perl libraries on Ubuntu 11.10 > -- > > Key: PROTON-437 > URL: https://issues.apache.org/jira/browse/PROTON-437 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce > > Even with the FindPerlLibs module it is still failing to find the Perl > libraries on Ubuntu. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*
[ https://issues.apache.org/jira/browse/PROTON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-448: --- Assignee: (was: Darryl L. Pierce) > Ruby bindings need to have their set calls updated to properly map values to > pn_data_t* > --- > > Key: PROTON-448 > URL: https://issues.apache.org/jira/browse/PROTON-448 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Darryl L. Pierce > > When using the APIs in Qpid::Proton::Data I'm seeing: > irb(main):001:0> require 'qpid_proton' > => true > irb(main):002:0> data = Qpid::Proton::Data.new > => # > irb(main):003:0> data.ubyte = 3 > value=3 > TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16 > in SWIG method 'pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `ubyte=' > from (irb):3 > from /usr/bin/irb:12:in `' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-347) pn_messenger_set_timeout leads to send hanging
[ https://issues.apache.org/jira/browse/PROTON-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-347: --- Labels: messenger (was: ) > pn_messenger_set_timeout leads to send hanging > -- > > Key: PROTON-347 > URL: https://issues.apache.org/jira/browse/PROTON-347 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Latest SVN checkout as of this morning >Reporter: Frank Quinn > Labels: messenger > Attachments: qpid_messenger_timeout_failure.c > > > A non-negative pn_messenger_set_timeout seems to result in pn_messenger_send > hanging with the following backtrace: > Thread 2 (Thread 0x7fee4c037700 (LWP 16763)): > #0 0x003518ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x7fee4c079a42 in pn_driver_wait_2 () >from /usr/local/lib64/libqpid-proton.so.1 > #2 0x7fee4c079cea in pn_driver_wait () >from /usr/local/lib64/libqpid-proton.so.1 > #3 0x7fee4c0744e4 in pn_messenger_tsync () >from /usr/local/lib64/libqpid-proton.so.1 > #4 0x7fee4c0747dc in pn_messenger_sync () >from /usr/local/lib64/libqpid-proton.so.1 > #5 0x7fee4c076327 in pn_messenger_recv () >from /usr/local/lib64/libqpid-proton.so.1 > #6 0x00400d31 in qpidListenerThread () > #7 0x003519407d15 in start_thread (arg=0x7fee4c037700) > at pthread_create.c:308 > #8 0x003518cf248d in clone () > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 > Thread 1 (Thread 0x7fee4c039840 (LWP 16762)): > #0 0x003519408e60 in pthread_join (threadid=140661454239488, > ---Type to continue, or q to quit--- > thread_return=0x0) at pthread_join.c:92 > #1 0x00400f11 in main () -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-639) pn_messenger_recv hangs / spins on connection refused
[
https://issues.apache.org/jira/browse/PROTON-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-639:
---
Labels: messenger (was: )
> pn_messenger_recv hangs / spins on connection refused
> -
>
> Key: PROTON-639
> URL: https://issues.apache.org/jira/browse/PROTON-639
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7, 0.8
> Environment: Red Hat Enterprise Linux 6.5
> kernel: 2.6.32-431.1.2.el6.x86_64
> qpid-proton 0.7 and 9939b8a990cd53c1b5e099c083bdcf61ad22232b git-svn-id:
> https://svn.apache.org/repos/asf/qpid/proton/trunk@1613151
> 13f79535-47bb-0310-9956-ffa450edef68
>Reporter: Rohan McGovern
> Labels: messenger
>
> If I try to connect to a closed port with a messenger, pn_messenger_recv
> outputs messages to stderr and then spins at high CPU usage, rather than
> returning with an error as expected.
> This seems to be impacted by kernel version. I have a RHEL 6.5 machine which
> demonstrates this problem reliably when using kernel
> 2.6.32-431.1.2.el6.x86_64 and not when using 3.10.28-1.el6.elrepo.x86_64 .
> This can be easily reproduced using the "recv" example in the qpid-proton
> sources.
> {noformat:title=kernel 2.6.32 - broken}
> $ build/examples/messenger/c/recv amqp://127.0.0.1:1
> recv: Connection refused
> [0x63d8e0]:ERROR amqp:connection:framing-error SASL header mismatch: ''
> CONNECTION ERROR connection aborted (remote)
> # hangs at this point with high CPU usage
> {noformat}
> Compare with the behavior on a later kernel version, which seems right:
> {noformat:title=kernel 3.10.28 - expected behavior}
> $ build/examples/messenger/c/recv amqp://127.0.0.1:1
> recv: Connection refused
> [0x15af8e0]:ERROR amqp:connection:framing-error SASL header mismatch: ''
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> /home/rmcgover/src/qpid-proton/examples/messenger/c/recv.c:132: no valid
> sources
> # exits with exit code 1
> {noformat}
> Here's a sample backtrace when the hang is occurring:
> {noformat}
> (gdb) bt
> #0 0x77ffea11 in clock_gettime ()
> #1 0x003a51e03e46 in clock_gettime () from /lib64/librt.so.1
> #2 0x77de6b5e in pn_i_now () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #3 0x77de4c06 in pn_selector_select () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #4 0x77ddf736 in pni_wait () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #5 0x77ddf869 in pn_messenger_tsync () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #6 0x77ddf8df in pn_messenger_sync () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #7 0x77de1676 in pn_messenger_recv () from
> /home/rmcgover/src/qpid-proton/build/proton-c/libqpid-proton.so.2
> #8 0x004014b2 in main ()
> {noformat}
> There's a while(true) loop in pn_messenger_tsync which seems like it never
> escapes. strace also shows that the process is repeatedly doing a poll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-356) PHP bindings are not built on MacOS 10.8
[ https://issues.apache.org/jira/browse/PROTON-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-356: --- Labels: osx (was: ) > PHP bindings are not built on MacOS 10.8 > > > Key: PROTON-356 > URL: https://issues.apache.org/jira/browse/PROTON-356 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: MacOS X 10.8, Homebrew >Reporter: Serge Smertin >Priority: Critical > Labels: osx > > it's not possible to build PHP extension for MacOS, as it gives linking > error. Relates to issue - https://issues.apache.org/jira/browse/PROTON-108, > which is not resolved properly. > Short-term viable solution: > - Attach *.so files to this ticket for macos x exactly > Long-term solution: > - Make proper linking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-346) Deadlock experienced in pn_messenger_stop
[ https://issues.apache.org/jira/browse/PROTON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-346: --- Labels: messenger (was: ) > Deadlock experienced in pn_messenger_stop > - > > Key: PROTON-346 > URL: https://issues.apache.org/jira/browse/PROTON-346 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Frank Quinn >Priority: Critical > Labels: messenger > Attachments: qpid_deadlock_repro.c > > > Hi Folks, > See attached code: I'm encountering a deadlock when I try to stop messengers. > The general workflow is: > 1. Create pub and sub Messengers > 2. Start the Messengers > 3. Thread sub off onto its own thread as recv is a blocking call > 4. Publish round trip from the pub messenger to the sub messenger with a > destroy subject (recv is uninteruptable at the moment so this is our only to > interrupt it) > 5. Stop the messengers > When I try and stop the messengers, the application deadlocks with the > following backtrace (there is only one thread running at this point as the > subscribe thread has since exited): > Thread 1 (Thread 0x7f38181a4840 (LWP 6688)): > #0 0x003518ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00309c226a1c in poll (__timeout=, __nfds= out>, __fds=) > at /usr/include/bits/poll2.h:46 > #2 pn_driver_wait_2 (d=d@entry=0x1a81140, timeout=, > timeout@entry=-1) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:752 > #3 0x00309c226c42 in pn_driver_wait (d=0x1a81140, > timeout=timeout@entry=-1) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:807 > #4 0x00309c2242d3 in pn_messenger_tsync (messenger=0x1a81050, > predicate=0x309c222d80 , timeout=) > at /usr/src/debug/qpid-proton-0.4/proton-c/src/messenger.c:623 > #5 0x00400ffb in main () at qpid_deadlock_repro.c:123 > I also tried adding the entire subscriber messenger workflow to the newly > created thread but the same behaviour persists (I'll be attaching the code to > recreate this shortly). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-395) Messenger - tracker-settled method is needed
[ https://issues.apache.org/jira/browse/PROTON-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-395: --- Labels: messenger (was: ) > Messenger - tracker-settled method is needed > > > Key: PROTON-395 > URL: https://issues.apache.org/jira/browse/PROTON-395 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: messenger > > Messenger has a way to query trackers to get the status of a message > delivery. However, there is no way to query the settlement of a delivery. > This is needed for the three-ack (exactly-once) exchange pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-782) pn_messenger_start always calls pn_messenger_resolve
[ https://issues.apache.org/jira/browse/PROTON-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-782: --- Labels: easyfix messenger (was: easyfix) > pn_messenger_start always calls pn_messenger_resolve > > > Key: PROTON-782 > URL: https://issues.apache.org/jira/browse/PROTON-782 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: David McCann > Labels: easyfix, messenger > Attachments: check_routes_only_when_specified.patch > > Original Estimate: 2m > Remaining Estimate: 2m > > Code was added to pn_messenger_start in 0.8 to allow a resolve to take place > immediately if PN_FLAGS_CHECK_ROUTES is set. > Unfortunately the check for the flag is incorrect, causing the resolve to > always take place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-388) Messenger lacks trace/debug logging
[ https://issues.apache.org/jira/browse/PROTON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-388: --- Labels: messenger (was: ) > Messenger lacks trace/debug logging > --- > > Key: PROTON-388 > URL: https://issues.apache.org/jira/browse/PROTON-388 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Affects Versions: 0.4 >Reporter: Ken Giusti > Labels: messenger > > There is no way to gain visibility into Messenger's internal state. We need > the ability to turn on trace logging to allow debugging messenger issues in > the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-201) Provide a C++ Messenger and Message class
[ https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-201. -- Resolution: Won't Fix > Provide a C++ Messenger and Message class > - > > Key: PROTON-201 > URL: https://issues.apache.org/jira/browse/PROTON-201 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Cliff Jansen > > Provide wrapper classes for these two types similar to what's available in > Perl and Ruby. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-938) [proton-J]Need ways to know temporary queue address created by Proton-J
[
https://issues.apache.org/jira/browse/PROTON-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-938:
---
Labels: documentation features messenger (was: documentation features)
> [proton-J]Need ways to know temporary queue address created by Proton-J
> ---
>
> Key: PROTON-938
> URL: https://issues.apache.org/jira/browse/PROTON-938
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.9.1
> Environment: Ubuntu Linux
>Reporter: yanfeng liu
> Labels: documentation, features, messenger
>
> It seems that Proton-J lacks the method to retrieve the address of a
> temporary queue created by Proton-J client application. The corresponding
> method exists in Proton-C like:
> {code:title=tempQueue.c|borderStyle=solid}
> // Subscribe w/ temp queue, print out the temp queue's name
> pn_subscription_t * sub = NULL;
> if ((sub = pn_messenger_subscribe(messenger, "amqps://10.69.3.1/#")) ==
> NULL) {
> printf("!!!queue %s does not exists\n",address);
> }
> printf("a subscribed address:%s\n",pn_subscription_address(sub));
> {code}
> However, in Proton-J, the Subscribe() method is defined as void.
> Regards,
> yf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-841) C recv example does not return disposition state
[ https://issues.apache.org/jira/browse/PROTON-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-841: --- Labels: messenger (was: ) > C recv example does not return disposition state > > > Key: PROTON-841 > URL: https://issues.apache.org/jira/browse/PROTON-841 > Project: Qpid Proton > Issue Type: Bug >Reporter: Matt Broadstone > Labels: messenger > > I apologize that I can't dig deeper into this for you, but I'm pressed for > time and figured it would still be meaningful feedback. I was recently > testing the rabbitmq amqp1.0 module against a number of amqp 1.0 clients, and > realized that when using the send/recv examples for the messenger api in > proton my recv client was disconnecting immediately after receiving a > message. > I submitted this > [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's > github and we traced the issue down to the fact that proton was not sending > back a state in the settled disposition frame upon receipt of the message > from the "send" client. The spec is incredibly ambiguous about what to do in > this scenario for brokers, and specifies that state is an optional field, but > at the same time the broker has no idea whether the message has been > acknowledged or rejects, simply that it has been settled. > Not sure how you guys want to go about this in your project, rabbitmq > gracefully handles this problem by closing the channel at this point (rather > than crashing as it did previously). > Anyway, just letting you know! > Cheers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-510) hostname field in the Open command is not set
[ https://issues.apache.org/jira/browse/PROTON-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088445#comment-15088445 ] Justin Ross commented on PROTON-510: [~tr...@redhat.com], has this changed? > hostname field in the Open command is not set > - > > Key: PROTON-510 > URL: https://issues.apache.org/jira/browse/PROTON-510 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Ted Ross > > If an address of the form "amqp://dns.domain.com/path" is used in > Proton/Messenger, when the connection is opened, the hostname field in the > Open should contain "dns.domain.com". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-344: --- Labels: message (was: ) > Need Ruby version of msgr-send/msgr-recv tools > -- > > Key: PROTON-344 > URL: https://issues.apache.org/jira/browse/PROTON-344 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: message > > A ruby variant of msgr-send/recv traffic generators should be added to the > soak tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-840) Fix Windows components to use transport logging
[ https://issues.apache.org/jira/browse/PROTON-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-840: --- Labels: windows (was: ) > Fix Windows components to use transport logging > --- > > Key: PROTON-840 > URL: https://issues.apache.org/jira/browse/PROTON-840 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8, 0.9 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > > Posix implemented new centralized logging. Windows needs to catch up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages
[
https://issues.apache.org/jira/browse/PROTON-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-766:
---
Labels: windows (was: )
> Proton-c Windows IO prints misleading error messages
>
>
> Key: PROTON-766
> URL: https://issues.apache.org/jira/browse/PROTON-766
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
> Environment: Windows Server 2012 R2
> Examples messaging c recv
>Reporter: Chuck Rolke
> Labels: windows
>
> Connecting to a port that is not open.
> Windows:
> {noformat}
> > send -a [::1]
> recv: No error
> [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch:
> ''
> CONNECTION ERROR connection aborted (remote)
> send: No error
> {noformat}
> The same action on Linux:
> {noformat}
> > ./send -a [::1]
> recv: Connection refused
> [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch:
> Insufficient data to determine protocol [''] (connection aborted)
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> {noformat}
> The Linux messages are more useful and indicate the precise error conditions.
> The Windows messages show recv: and send: with 'No error' and that is not the
> case.
> The same error message is displayed for IPv4 and IPv6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-599) Visual Studio warnings - enumeration update
[ https://issues.apache.org/jira/browse/PROTON-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-599: --- Labels: windows (was: ) > Visual Studio warnings - enumeration update > --- > > Key: PROTON-599 > URL: https://issues.apache.org/jira/browse/PROTON-599 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Visual Studio 2008, 2010, 2012, 2013 >Reporter: Chuck Rolke > Labels: windows > Attachments: vs-proton-warnings.txt > > > After suppressing the 'usual' warnings (see PROTON-546, > http://svn.apache.org/r1601010) and running some later compiler versions a > new list of errors emerges. Please see attached listing for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-598) CProton python binding fails to build Windows debug configuration
[ https://issues.apache.org/jira/browse/PROTON-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-598: --- Labels: windows (was: window) > CProton python binding fails to build Windows debug configuration > - > > Key: PROTON-598 > URL: https://issues.apache.org/jira/browse/PROTON-598 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Windows, Python 2.6.1 >Reporter: Chuck Rolke > Labels: windows > > cpython fails to link with file python26_d.lib not found. > The issue here is that the windows installer for python does not install the > debug versions (identified by the _d suffix) of the python libraries. Wisdom > from the web suggests either to build your own debug python or to debug using > a release build. > Links using the RelWithDebInfo work just fine and I can make progress running > ctest. Just a heads up for anyone who wants to run ctest with Debug builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[
https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-411:
---
Labels: windows (was: )
> [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
> -
>
> Key: PROTON-411
> URL: https://issues.apache.org/jira/browse/PROTON-411
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.4
> Environment: Windows
>Reporter: Chuck Rolke
> Labels: windows
>
> Windows needs something other than hard coded
> Libs: -L${libdir -lqpid-proton
> Cflags: -I${includedir}}
> All the other computed values configured into this file are correct: PREFIX,
> EXEC_PREFIX, LIBDIR, INCLUDEDIR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-405) [proton-c] Windows install fails to find proton-api.jar file
[ https://issues.apache.org/jira/browse/PROTON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-405: --- Labels: windows (was: ) > [proton-c] Windows install fails to find proton-api.jar file > > > Key: PROTON-405 > URL: https://issues.apache.org/jira/browse/PROTON-405 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows install >Reporter: Chuck Rolke > Labels: windows > > The install script is looking for file > 4> CMake Error at proton-j/proton-api/cmake_install.cmake:31 (FILE): > 4>file INSTALL cannot find > 4>"D:/Users/crolke/svn/proton/build/proton-j/proton-api/proton-api.jar". > but the actual file is versioned > Directory of D:\Users\chug\svn\proton\build\proton-j\proton-api > 08/17/2013 10:04 AM 120,690 proton-api-0.5.jar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1041) Add recurring timer example to the reactive C++ documentation
[ https://issues.apache.org/jira/browse/PROTON-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1041: Labels: patch (was: ) > Add recurring timer example to the reactive C++ documentation > - > > Key: PROTON-1041 > URL: https://issues.apache.org/jira/browse/PROTON-1041 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0, 0.12.0 >Reporter: Otavio Rodolfo Piske >Assignee: Cliff Jansen >Priority: Minor > Labels: patch > Attachments: recurring-timer-example.patch > > > The C++ documentation is missing the recurring_timer.cpp example in its > documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-609) Assert in messenger.py test causes core dump
[
https://issues.apache.org/jira/browse/PROTON-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-609:
---
Labels: messenger (was: )
> Assert in messenger.py test causes core dump
>
>
> Key: PROTON-609
> URL: https://issues.apache.org/jira/browse/PROTON-609
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7
> Environment: Windows or Linux
>Reporter: Chuck Rolke
> Labels: messenger
>
> This assert:
> {noformat}
> Index: tests/python/proton_tests/messenger.py
> ===
> --- tests/python/proton_tests/messenger.py(revision 1602460)
> +++ tests/python/proton_tests/messenger.py(working copy)
> @@ -843,6 +843,7 @@
> msg2 = Message()
> msg2.address = self.address + "/msg2"
> self.client.put(msg2)
> +assert False, "Whoops!"
> self.pump()
> assert self.server.incoming == 1, self.server.incoming
> assert self.server.receiving == 8, self.server.receiving
> {noformat}
> causes a core dump in NBMessengerTest.teardown when the code tries to stop
> the client. A user may work around this issue by
> {noformat}
> + if msgr.outgoing > 0:
> +msgr.settle()
> + while msgr.incoming > 0:
> +msgr.get()
> + msgr.stop()
> {noformat}
> when all he wants is msgr.stop().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-568) messenger client slows and grows with large address space
[ https://issues.apache.org/jira/browse/PROTON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-568: --- Labels: messenger (was: ) > messenger client slows and grows with large address space > - > > Key: PROTON-568 > URL: https://issues.apache.org/jira/browse/PROTON-568 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish > Labels: messenger > > A messenger-based sending client grows from little memory to over 3 GB, and > slows down by at least 10x, when transmitting 1 message each to many > addresses. > here is the setup: > 1. a single messenger-based sender. > 2. a single dispatch router > 3. 5000 messenger-based receivers, each listening to 10 unique addresses. > i.e. 50,000 unique addresses total. > 4. the sender sends a single to each unique address. > 5. the first 10 messages go to addr1 ... addr10 -- all of which belong to the > first receiver. > 6. when each receiver gets all 10 of its messages, it shuts down. > 7. each message is 1-to-1, and fire-and-forget. > 8. This means that the sender only sends 1 message to each address and then > moves on, never to return. > Result > --- > The sending application started out doing something like 100-200 messages per > second. Its memory footprint was small. > By the time I reach 13,000 messages sent, output has fallen to about 25 > messages per second, and memory (RSS) has risen to about 1.7 GB. > It keeps getting larger and slower until the user rebels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-398) pn_messenger_subscribe() fails to create a listener
[
https://issues.apache.org/jira/browse/PROTON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-398:
---
Labels: messenger (was: )
> pn_messenger_subscribe() fails to create a listener
> ---
>
> Key: PROTON-398
> URL: https://issues.apache.org/jira/browse/PROTON-398
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, proton-j
>Affects Versions: 0.5
> Environment: linux (fedora 14 64bit)
>Reporter: Marc Berkowitz
> Labels: messenger
>
> Running a local ActiveMQ server, release 5.8.0, default configuration.
> The documented "listen all' feature of the python example fails with the error
> 'bind: Address already in use.'
> cd proton/examples/messenger/py;
> ./recv.py amqp://localhost/test -- subscribes to a specified address,
> and works
> ./recv.py OR ./recv.py amqp://~localhost -- listens to all addresses,
> and fails.
> py/recv.py amqp://~localhost
> Traceback (most recent call last):
> File "py/recv.py", line 41, in mng.subscribe(a)
> File "/usr/lib64/python2.7/site-packages/proton.py", line 371, in subscribe
> self._check(PN_ERR)
> File "/usr/lib64/python2.7/site-packages/proton.py", line 228, in _check
> raise exc("[%s]: %s" % (err, pn_messenger_error(self._mng)))
> proton.MessengerException: [-2]: unable to subscribe to source:
> amqp://~localhost
> (bind: Address already in use)
> Same error from a similar java program, which calls proton-j.
> Both fail trying to bind to localhost:5672, which is held by the local
> activemq server.
> Must either fix the ~ADDRESS feature or remove it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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)
