[jira] [Updated] (PROTON-1180) [C++ binding] Change endpoint API
[ https://issues.apache.org/jira/browse/PROTON-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1180: Summary: [C++ binding] Change endpoint API (was: [C++ binding] Change endpoit API) > [C++ binding] Change endpoint API > - > > Key: PROTON-1180 > URL: https://issues.apache.org/jira/browse/PROTON-1180 > Project: Qpid Proton > Issue Type: Improvement > Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > > * Rename remote_condition to condition; remove local_condition (the remote > state is authoritative) > * Add boolean accessors for uninitialized, active, and closed; remove > endpoint.state bit field > * Lift close operation to endpoint from its descendents > * Add new close operation with condition arg -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1180) [C++ binding] Change endpoit API
Andrew Stitcher created PROTON-1180: --- Summary: [C++ binding] Change endpoit API Key: PROTON-1180 URL: https://issues.apache.org/jira/browse/PROTON-1180 Project: Qpid Proton Issue Type: Improvement Reporter: Andrew Stitcher * Rename remote_condition to condition; remove local_condition (the remote state is authoritative) * Add boolean accessors for uninitialized, active, and closed; remove endpoint.state bit field * Lift close operation to endpoint from its descendents * Add new close operation with condition arg -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1180) [C++ binding] Change endpoit API
[ https://issues.apache.org/jira/browse/PROTON-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1180: --- Assignee: Andrew Stitcher > [C++ binding] Change endpoit API > > > Key: PROTON-1180 > URL: https://issues.apache.org/jira/browse/PROTON-1180 > Project: Qpid Proton > Issue Type: Improvement > Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > > * Rename remote_condition to condition; remove local_condition (the remote > state is authoritative) > * Add boolean accessors for uninitialized, active, and closed; remove > endpoint.state bit field > * Lift close operation to endpoint from its descendents > * Add new close operation with condition arg -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1179) [C++ binding] Rework condition class
Andrew Stitcher created PROTON-1179: --- Summary: [C++ binding] Rework condition class Key: PROTON-1179 URL: https://issues.apache.org/jira/browse/PROTON-1179 Project: Qpid Proton Issue Type: Improvement Reporter: Andrew Stitcher * Rename condition to error_condition * rename info member to properties * change it from a pure wrapper of pn_condition_t to be a value type. ** privately constructed from a pn_condition_t ** API constructed from name [description [properties] ] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1179) [C++ binding] Rework condition class
[ https://issues.apache.org/jira/browse/PROTON-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1179: --- Assignee: Andrew Stitcher > [C++ binding] Rework condition class > > > Key: PROTON-1179 > URL: https://issues.apache.org/jira/browse/PROTON-1179 > Project: Qpid Proton > Issue Type: Improvement > Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > > * Rename condition to error_condition > * rename info member to properties > * change it from a pure wrapper of pn_condition_t to be a value type. > ** privately constructed from a pn_condition_t > ** API constructed from name [description [properties] ] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228410#comment-15228410
]
Andrew Stitcher commented on PROTON-1135:
-
This is fixed by no longer sending pipelined frames from SASL into AMQP frames.
I've modified the tests so that we are still testing that proton-c correctly
handles incoming pipelined frames (by generating the frames by hand and
hardcoding them in the test). So this should ensure that we do carry on
accepting pipelined frames.
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>Assignee: Andrew Stitcher
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
> <- AMQP%d3.1.0.0
> :
> :
>
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher reassigned PROTON-1135:
---
Assignee: Andrew Stitcher
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>Assignee: Andrew Stitcher
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
> <- AMQP%d3.1.0.0
> :
> :
>
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214511#comment-15214511
]
Andrew Stitcher commented on PROTON-1135:
-
Fair enough - I certainly regard a comment from a spec author as more
authoritative than my comments!
In this case I'd say that we should stop pipelining SASL and AMQP protocol
layers completely both client and server side.
In this case my concern that we will be unable to test server pipelining no
longer exists as we won't support that either.
To be clear the complexities are implementing the mixed pipelining across
layers - this change should not affect pipelining with only the AMQP layer
present. And we should still be able to test that.
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
> <- AMQP%d3.1.0.0
> :
> :
>
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214365#comment-15214365
]
Andrew Stitcher commented on PROTON-1135:
-
As far as I can tell that the diagram in the description from the AMQP spec is
not normative but merely descriptive.
However there is a whole section in the standard "2.4.2 Pipelined Open" which
strongly implies that pipelined open is a normative part of the protocol and so
every conforming implementation MUST implement it.
It is unfortunate the section 2.4.2 doesn't specifically discuss the
implications of pipelined open to the SASL protocol interchange, but I think it
is clear that where those frames can be pipelined they must be accepted too. I
think that "open" in the sense of that paragraph implies the entire protocol up
to and including sending the AMQP open frame.
Client implementation are not required to pipeline, but server implementations
must be able to cope with it as I read that paragraph.
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
> <- AMQP%d3.1.0.0
> :
> :
>
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1164) Update handlers to align with current proposal
Andrew Stitcher created PROTON-1164: --- Summary: Update handlers to align with current proposal Key: PROTON-1164 URL: https://issues.apache.org/jira/browse/PROTON-1164 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher The current event handler proposal includes the primary object that the event is concerned with in the handler signature. This makes it more convenient to process the event by giving the most likely object to be needed directly to the handler without any other lookups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1156) Building C++ binding causes VS2008 to ICE
[
https://issues.apache.org/jira/browse/PROTON-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187535#comment-15187535
]
Andrew Stitcher commented on PROTON-1156:
-
Building on a different box I get an ICE inside a MS header file instead
(utility.h) So I'm not clear if we can actually figure out which is the
responsible file.
> Building C++ binding causes VS2008 to ICE
> -
>
> Key: PROTON-1156
> URL: https://issues.apache.org/jira/browse/PROTON-1156
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0
> Environment: Windows Visual Studio 2008 (VS9)
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
>
> {noformat}
> 3>c:\jenkins\workspace\proton-c-master-windows\rh-qpid-proton\proton-c\bindings\cpp\src\terminus.cpp(29)
> : fatal error C1001: An internal error has occurred in the compiler.
> 3>(compiler file
> 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x6C510CA6:0x0010]', line 182)
> 3> To work around this problem, try simplifying or changing the program near
> the locations listed above.
> 3>Please choose the Technical Support command on the Visual C++
> 3> Help menu, or open the Technical Support help file for more information
> 3>Internal Compiler Error in C:\Program Files\Microsoft Visual Studio
> 9.0\VC\bin\cl.exe. You will be prompted to send an error report to Microsoft
> later.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1156) Building C++ binding causes VS2008 to ICE
[
https://issues.apache.org/jira/browse/PROTON-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186542#comment-15186542
]
Andrew Stitcher commented on PROTON-1156:
-
The code at the referenced pint in terminus.cpp seems entirely oridnary to me.
Perhaps we should just not support VS2008, and require 2010 and on.
> Building C++ binding causes VS2008 to ICE
> -
>
> Key: PROTON-1156
> URL: https://issues.apache.org/jira/browse/PROTON-1156
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0
> Environment: Windows Visual Studio 2008 (VS9)
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
>
> {noformat}
> 3>c:\jenkins\workspace\proton-c-master-windows\rh-qpid-proton\proton-c\bindings\cpp\src\terminus.cpp(29)
> : fatal error C1001: An internal error has occurred in the compiler.
> 3>(compiler file
> 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x6C510CA6:0x0010]', line 182)
> 3> To work around this problem, try simplifying or changing the program near
> the locations listed above.
> 3>Please choose the Technical Support command on the Visual C++
> 3> Help menu, or open the Technical Support help file for more information
> 3>Internal Compiler Error in C:\Program Files\Microsoft Visual Studio
> 9.0\VC\bin\cl.exe. You will be prompted to send an error report to Microsoft
> later.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1156) Building C++ binding causes VS2008 to ICE
Andrew Stitcher created PROTON-1156:
---
Summary: Building C++ binding causes VS2008 to ICE
Key: PROTON-1156
URL: https://issues.apache.org/jira/browse/PROTON-1156
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Affects Versions: 0.13.0
Environment: Windows Visual Studio 2008 (VS9)
Reporter: Andrew Stitcher
Assignee: Cliff Jansen
{noformat}
3>c:\jenkins\workspace\proton-c-master-windows\rh-qpid-proton\proton-c\bindings\cpp\src\terminus.cpp(29)
: fatal error C1001: An internal error has occurred in the compiler.
3>(compiler file
'f:\dd\vctools\compiler\utc\src\p2\main.c[0x6C510CA6:0x0010]', line 182)
3> To work around this problem, try simplifying or changing the program near
the locations listed above.
3>Please choose the Technical Support command on the Visual C++
3> Help menu, or open the Technical Support help file for more information
3>Internal Compiler Error in C:\Program Files\Microsoft Visual Studio
9.0\VC\bin\cl.exe. You will be prompted to send an error report to Microsoft
later.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1154) Travis CI failing due to valgrind problems
[ https://issues.apache.org/jira/browse/PROTON-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1154: Assignee: (was: Andrew Stitcher) > Travis CI failing due to valgrind problems > -- > > Key: PROTON-1154 > URL: https://issues.apache.org/jira/browse/PROTON-1154 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 > Environment: Ubuntu 12.04 Travis CI test environment >Reporter: Andrew Stitcher > Fix For: 0.13.0 > > > 2 of the tests in cpp_example_container_test (test_ssl & > test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 > build environment. > It looks like the issues are due to the specific environment on that > machine/that version of Ubuntu as other environments don't seem to fail these > tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1154) Travis CI failing due to valgrind problems
[ https://issues.apache.org/jira/browse/PROTON-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1154: Fix Version/s: 0.13.0 > Travis CI failing due to valgrind problems > -- > > Key: PROTON-1154 > URL: https://issues.apache.org/jira/browse/PROTON-1154 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 > Environment: Ubuntu 12.04 Travis CI test environment >Reporter: Andrew Stitcher > Fix For: 0.13.0 > > > 2 of the tests in cpp_example_container_test (test_ssl & > test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 > build environment. > It looks like the issues are due to the specific environment on that > machine/that version of Ubuntu as other environments don't seem to fail these > tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1154) Travis CI failing due to valgrind problems
[ https://issues.apache.org/jira/browse/PROTON-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178585#comment-15178585 ] Andrew Stitcher commented on PROTON-1154: - I've put in a work around for now - but I don't really consider the issue fully resolved. > Travis CI failing due to valgrind problems > -- > > Key: PROTON-1154 > URL: https://issues.apache.org/jira/browse/PROTON-1154 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 > Environment: Ubuntu 12.04 Travis CI test environment >Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > Fix For: 0.13.0 > > > 2 of the tests in cpp_example_container_test (test_ssl & > test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 > build environment. > It looks like the issues are due to the specific environment on that > machine/that version of Ubuntu as other environments don't seem to fail these > tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1154) Travis CI failing due to valgrind problems
[ https://issues.apache.org/jira/browse/PROTON-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1154. - Resolution: Incomplete > Travis CI failing due to valgrind problems > -- > > Key: PROTON-1154 > URL: https://issues.apache.org/jira/browse/PROTON-1154 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 > Environment: Ubuntu 12.04 Travis CI test environment >Reporter: Andrew Stitcher > > 2 of the tests in cpp_example_container_test (test_ssl & > test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 > build environment. > It looks like the issues are due to the specific environment on that > machine/that version of Ubuntu as other environments don't seem to fail these > tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1154) Travis CI failing due to valgrind problems
[ https://issues.apache.org/jira/browse/PROTON-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178560#comment-15178560 ] Andrew Stitcher commented on PROTON-1154: - This is a major issue as this CI build is very visible and having it fail makes it impossible to validate source changes before they are merged. > Travis CI failing due to valgrind problems > -- > > Key: PROTON-1154 > URL: https://issues.apache.org/jira/browse/PROTON-1154 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 > Environment: Ubuntu 12.04 Travis CI test environment >Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > > 2 of the tests in cpp_example_container_test (test_ssl & > test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 > build environment. > It looks like the issues are due to the specific environment on that > machine/that version of Ubuntu as other environments don't seem to fail these > tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1154) Travis CI failing due to valgrind problems
Andrew Stitcher created PROTON-1154: --- Summary: Travis CI failing due to valgrind problems Key: PROTON-1154 URL: https://issues.apache.org/jira/browse/PROTON-1154 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.13.0 Environment: Ubuntu 12.04 Travis CI test environment Reporter: Andrew Stitcher Assignee: Andrew Stitcher 2 of the tests in cpp_example_container_test (test_ssl & test_ssl_client_cert) fail due to valgrind problems on the Travis CI 12.04 build environment. It looks like the issues are due to the specific environment on that machine/that version of Ubuntu as other environments don't seem to fail these tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1152) [C++ binding] Make sure non API details in classes are private
Andrew Stitcher created PROTON-1152: --- Summary: [C++ binding] Make sure non API details in classes are private Key: PROTON-1152 URL: https://issues.apache.org/jira/browse/PROTON-1152 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1153) [C++ binding] Tidy up various details
Andrew Stitcher created PROTON-1153: --- Summary: [C++ binding] Tidy up various details Key: PROTON-1153 URL: https://issues.apache.org/jira/browse/PROTON-1153 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1151) [C++ binding] Move exposed implementation details into proton::internal namespace
Andrew Stitcher created PROTON-1151: --- Summary: [C++ binding] Move exposed implementation details into proton::internal namespace Key: PROTON-1151 URL: https://issues.apache.org/jira/browse/PROTON-1151 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: QPID Proton 12 Issue - can anyone help?
On Mon, 2016-02-29 at 17:46 +, Flores, Paul A. wrote: > I am attempting to build QPID Proton 12 and seeing the following > errors: > > > > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > ImportError: No module named site > make[2]: *** [proton-c/src/protocol.h] Error 1 > ImportError: No module named site > make[2]: *** [proton-c/src/encodings.h] Error 1 This error is happening because the version of python that cmake has found is wrong and so it can't run python to generate these files. > ... > (WHY > > -- Found PythonInterp: /usr/bin/python (found version "1.4") > > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES > PYTHON_INCLUDE_DIRS) (Required is exact version "1.4") > > ) You appear to have a python 1.4 version installed so that cmake found it in preference to a more useful version of python. Try setting your path so that it isn't found before you run cmake. (1.4 seems odd though as it is so old) Andrew
[jira] [Resolved] (PROTON-1144) IPv6 addresses could be truncated by the accept code
[ https://issues.apache.org/jira/browse/PROTON-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1144. - Resolution: Fixed > IPv6 addresses could be truncated by the accept code > > > Key: PROTON-1144 > URL: https://issues.apache.org/jira/browse/PROTON-1144 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: 0.12.0 > Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1142) Remove proton-dump executable
[ https://issues.apache.org/jira/browse/PROTON-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1142. - Resolution: Fixed > Remove proton-dump executable > - > > Key: PROTON-1142 > URL: https://issues.apache.org/jira/browse/PROTON-1142 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.12.0 > Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.13.0 > > > Remove the old and creaky proton-dump executable. > As discussed in: > http://qpid.2158936.n2.nabble.com/Dropping-proton-dump-Moving-to-newer-minimum-CMake-version-td7638474.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1142) Remove proton-dump executable
[ https://issues.apache.org/jira/browse/PROTON-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1142: --- Assignee: Andrew Stitcher > Remove proton-dump executable > - > > Key: PROTON-1142 > URL: https://issues.apache.org/jira/browse/PROTON-1142 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.12.0 > Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.13.0 > > > Remove the old and creaky proton-dump executable. > As discussed in: > http://qpid.2158936.n2.nabble.com/Dropping-proton-dump-Moving-to-newer-minimum-CMake-version-td7638474.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1144) IPv6 addresses could be truncated by the accept code
Andrew Stitcher created PROTON-1144: --- Summary: IPv6 addresses could be truncated by the accept code Key: PROTON-1144 URL: https://issues.apache.org/jira/browse/PROTON-1144 Project: Qpid Proton Issue Type: Bug Components: cpp-binding, proton-c Affects Versions: 0.12.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1143) Bump Minimum version of CMake to 2.8.7
Andrew Stitcher created PROTON-1143: --- Summary: Bump Minimum version of CMake to 2.8.7 Key: PROTON-1143 URL: https://issues.apache.org/jira/browse/PROTON-1143 Project: Qpid Proton Issue Type: Improvement Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Fix For: 0.13.0 As discussed in: http://qpid.2158936.n2.nabble.com/Dropping-proton-dump-Moving-to-newer-minimum-CMake-version-td7638474.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1142) Remove proton-dump executable
Andrew Stitcher created PROTON-1142: --- Summary: Remove proton-dump executable Key: PROTON-1142 URL: https://issues.apache.org/jira/browse/PROTON-1142 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.12.0 Reporter: Andrew Stitcher Priority: Minor Fix For: 0.13.0 Remove the old and creaky proton-dump executable. As discussed in: http://qpid.2158936.n2.nabble.com/Dropping-proton-dump-Moving-to-newer-minimum-CMake-version-td7638474.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-250) Add -fvisibility option when building shared libraries
[ https://issues.apache.org/jira/browse/PROTON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-250. Resolution: Fixed Fix Version/s: 0.13.0 > Add -fvisibility option when building shared libraries > --- > > Key: PROTON-250 > URL: https://issues.apache.org/jira/browse/PROTON-250 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: GNU Compiler >Reporter: Irina Boverman > Assignee: Andrew Stitcher >Priority: Minor > Labels: patch > Fix For: 0.13.0 > > Attachments: proton.patch > > > Add an option to "hide" symbols in shared libraries except when they are > declared public. > Extends efforts already in place for Windows builds. > Excludes an effort to determine what symbols should be considered "public" > interfaces. > The gcc 4 -fvisibility option is said to: > ...very substantially improve linking and load times of shared object > libraries, produce more optimized code, provide near-perfect API export and > prevent symbol clashes. It is strongly recommended that you use this in any > shared objects you distribute. > See here: http://gcc.gnu.org/wiki/Visibility > Attached patch (patch.txt) will build libqpid-proton.so shared library using > this flag. > It reduces number of symbols from 700+ to 500+. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 ] Andrew Stitcher resolved PROTON-405. Resolution: Fixed Fix Version/s: 0.13.0 > [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 > Fix For: 0.13.0 > > > 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)
Re: Dropping proton-dump; Moving to newer minimum CMake version
Well I left it 3 days, heard no objections so I will remove proton-dump and up the minimum version of cmake to 2.8.7. Andrew
Re: Error compiling proton C++ binding 0.12 with GCC 3.4
On Wed, 2016-02-17 at 10:51 +, TRUFANOW Alexandre wrote: > Hi, > > I am attempting to compile proton and the C++ binding using GCC 3.4 This is a very old compiler (from no later than 2006), and we don't test on it (although we are striving currently to support C++03). Going forward it is not too unlikely that we will move to using C++11 features for our implementation. So if you can use a more recent version of gcc (or clang) then you will be better off. > and > get the following error when compiling the C++ bindings. (compiler > flags > have been removed in proton-c/CMakeLists.txt: -pedantic-errors > -Wno-variadic-macros) > > > [ 33%] Building CXX object proton-c/bindings/cpp/CMakeFiles/qpid- > > proton-cpp.dir/src/acceptor.cpp.o > > In file included from /tmp/qpid-proton-0.12.0/proton- > > c/bindings/cpp/src/contexts.hpp:28, > > from /tmp/qpid-proton-0.12.0/proton- > > c/bindings/cpp/src/acceptor.cpp:26: > > /tmp/qpid-proton-0.12.0/proton- > > c/bindings/cpp/include/proton/container.hpp:129: error: declaration > > of `void proton::container::link_options(const > > proton::link_options&)' > > /tmp/qpid-proton-0.12.0/proton- > > c/bindings/cpp/include/proton/link_options.hpp:60: error: changes > > meaning of `link_options' from `class proton::link_options' > > make[2]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton- > > cpp.dir/src/acceptor.cpp.o] Error 1 > > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton- > > cpp.dir/all] Error 2 > > From what I understand, this is due to a clash between the class > proton::link_options and the method proton::container::link_options > which cannot have the same name. As far as I can tell (and the compilers we test on seem to agree) there is no name clash here (it is probably a name lookup bug in the compiler)! You could try explicitly making the declaration: void link_options(const proton::link_options&); But I doubt this will help, as the compiler seems to know this already and the name is not ambiguous. HTH Andrew
Re: Dropping proton-dump; Moving to newer minimum CMake version
On Mon, 2016-02-15 at 17:36 -0500, Ken Giusti wrote: > ... > In general +1. What version does Windows use? In general Windows builds will use whatever you install on them (as CMake isn't packaged with Windows in anyway). Specifically the version packaged by chocolatey (http://chocolatey.org) is currently 3.4.3 - So if you use those packages and keep up to date you'll have that. Andrew
Re: Dropping proton-dump; Moving to newer minimum CMake version
On Mon, 2016-02-15 at 17:16 -0500, Chuck Rolke wrote: > .. > > I use a minimum CMake of 2.8.11 on my windows systems. Thanks for the info - FWIW I'd upgrade to atleast 2.8.12 If I were you (it's the last 2.8 version before they jumped to 3.x) Andrew
Dropping proton-dump; Moving to newer minimum CMake version
I've been doing some build tree maintenance in Proton and a couple of issues have come up: 1. Is anyone using/have a reason to want to keep proton-dump? It's a somewhat odd program that seems to have been a debugging tool left over from the very earliest days of proton. It uses the internals of the proton-c library so it can't be simply linked in with the qpid-proton library without exposing internal symbols. For the present I've just linked it directly with the few c files that provide the symbols it needs. 2. I'd like to move the minimum required CMake version to 2.8.7 - This will allow me to tidy up a certain amount of the build system and also provide a somewhat more featureful base version of CMake (currently we support 2.6 onwards) As far as I can tell: Ubuntu12.04LTS: CMake 2.8.7 (version on regular TravisCI build) RHEL6: CMake 2.8.12 Debian Wheezy (7): CMake 2.8.9 Fedora 22: CMake 3.4.1 Version of CMake on appveyor currently seems to be at least 3.3.2 So I don't think there should be a probelm for anyone with this change. I'll wait for 3 days and if I don't hear anything from anyone, I'll assume that no one wants to keep proton-dump and no one objects to upping the minimum supported version of CMake. Thanks Andrew
[jira] [Resolved] (PROTON-988) pn_messenger_set_flags does not support new SASL flag correctly
[ https://issues.apache.org/jira/browse/PROTON-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-988. Resolution: Fixed Fix Version/s: 0.13.0 I've fixed the blatant issue here, but I've not made the API any more sensible. And I didn't add any tests for this API as there is no sensible place to do it currently! > pn_messenger_set_flags does not support new SASL flag correctly > --- > > Key: PROTON-988 > URL: https://issues.apache.org/jira/browse/PROTON-988 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 > Environment: All OS >Reporter: Clemens Vasters > Assignee: Andrew Stitcher > Labels: messenger > Fix For: 0.13.0 > > > The new flag PN_FLAGS_ALLOW_INSECURE_MECHS cannot be set though > pn_messenger_set_flags. > Setting the other defined flag, PN_FLAGS_CHECK_ROUTES, causes the preset > PN_FLAGS_ALLOW_INSECURE_MECHS to be irrecoverably overridden. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-629) Can't include proton-c header files in c-only applications in visual studio
[ https://issues.apache.org/jira/browse/PROTON-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-629. Resolution: Fixed Fix Version/s: 0.13.0 > Can't include proton-c header files in c-only applications in visual studio > --- > > Key: PROTON-629 > URL: https://issues.apache.org/jira/browse/PROTON-629 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Windows >Reporter: Sahir Hoda > Assignee: Andrew Stitcher > Labels: easyfix, patch > Fix For: 0.13.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > The public API for the proton-c library includes the function in delivery.h: > 61:static inline pn_delivery_tag_t pn_dtag(const char *bytes, size_t size) > The 'inline' keyword is problematic for applications building with Visual > Studio in a non-C++ mode. Per the msdn doc > [http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx]: > "The inline keyword is available only in C++. The __inline and __forceinline > keywords are available in both C and C++. For compatibility with previous > versions, _inline is a synonym for __inline." > So 'inline' is only available for C++ applications, however C applications > must use the '__inline' keyword instead. > To resolve this issue, I would suggest the following patch: > diff --git a/proton-c/include/proton/type_compat.h > b/proton-c/include/proton/type_compat.h > index 9501d9a..9423cf1 100644 > --- a/proton-c/include/proton/type_compat.h > +++ b/proton-c/include/proton/type_compat.h > @@ -130,4 +130,9 @@ typedef unsigned __int64 uint64_t; > # endif > #endif // PNI_DEFINE_SSIZE_T > > +#if !defined(__cplusplus) && defined(_MSC_VER) > +// visual studio and not using c++ > + #define inline __inline > +#endif > + > #endif /* type_compat.h */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-629) Can't include proton-c header files in c-only applications in visual studio
[ https://issues.apache.org/jira/browse/PROTON-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-629: --- Labels: easyfix patch (was: build easyfix patch) > Can't include proton-c header files in c-only applications in visual studio > --- > > Key: PROTON-629 > URL: https://issues.apache.org/jira/browse/PROTON-629 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Windows >Reporter: Sahir Hoda > Assignee: Andrew Stitcher > Labels: easyfix, patch > Original Estimate: 1h > Remaining Estimate: 1h > > The public API for the proton-c library includes the function in delivery.h: > 61:static inline pn_delivery_tag_t pn_dtag(const char *bytes, size_t size) > The 'inline' keyword is problematic for applications building with Visual > Studio in a non-C++ mode. Per the msdn doc > [http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx]: > "The inline keyword is available only in C++. The __inline and __forceinline > keywords are available in both C and C++. For compatibility with previous > versions, _inline is a synonym for __inline." > So 'inline' is only available for C++ applications, however C applications > must use the '__inline' keyword instead. > To resolve this issue, I would suggest the following patch: > diff --git a/proton-c/include/proton/type_compat.h > b/proton-c/include/proton/type_compat.h > index 9501d9a..9423cf1 100644 > --- a/proton-c/include/proton/type_compat.h > +++ b/proton-c/include/proton/type_compat.h > @@ -130,4 +130,9 @@ typedef unsigned __int64 uint64_t; > # endif > #endif // PNI_DEFINE_SSIZE_T > > +#if !defined(__cplusplus) && defined(_MSC_VER) > +// visual studio and not using c++ > + #define inline __inline > +#endif > + > #endif /* type_compat.h */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1128) [C++ binding] Symbol exports use wrong directive for proton::condition
[ https://issues.apache.org/jira/browse/PROTON-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1128. - Resolution: Fixed Fix Version/s: 0.13.0 > [C++ binding] Symbol exports use wrong directive for proton::condition > -- > > Key: PROTON-1128 > URL: https://issues.apache.org/jira/browse/PROTON-1128 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 > Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.13.0 > > > The C++ binding API header file incorrectly uses PN_CPP_EXPORT rather than > PN_CPP_EXTERN. > In theory on Windows (the only system where these directives are currently > active) this could mean that user programs using the proton::condition API > would be unable to do so as the program would be exporting the API rather > than importing it. > However in limited tests using VS 2015 it doesn't seem to actually be causing > a problem. > It may be that it is problematic in other (earlier) VS compilers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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:all-tabpanel ] Andrew Stitcher resolved PROTON-1127. - Resolution: Fixed > [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] [Resolved] (PROTON-1124) Small problems detected by Coverity scanner
[ https://issues.apache.org/jira/browse/PROTON-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1124. - Resolution: Fixed Fix Version/s: 0.13.0 > Small problems detected by Coverity scanner > --- > > Key: PROTON-1124 > URL: https://issues.apache.org/jira/browse/PROTON-1124 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Reporter: Andrew Stitcher > Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.13.0 > > > Some minor problems detected in proton-c by Coverity scan of Jan 31 2016 > master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1128) [C++ binding] Symbol exports use wrong directive for proton::condition
Andrew Stitcher created PROTON-1128: --- Summary: [C++ binding] Symbol exports use wrong directive for proton::condition Key: PROTON-1128 URL: https://issues.apache.org/jira/browse/PROTON-1128 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.12.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor The C++ binding API header file incorrectly uses PN_CPP_EXPORT rather than PN_CPP_EXTERN. In theory on Windows (the only system where these directives are currently active) this could mean that user programs using the proton::condition API would be unable to do so as the program would be exporting the API rather than importing it. However in limited tests using VS 2015 it doesn't seem to actually be causing a problem. It may be that it is problematic in other (earlier) VS compilers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Qpid Proton 0.12.0
On Wed, 2016-02-03 at 07:10 -0800, Justin Ross wrote: > The artifacts proposed for release: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ > > Please indicate your vote below. If you favor releasing the 0.12.0 > RC bits > as 0.12.0 GA, vote +1. If you have reason to think the RC is not > ready for > release, vote -1. -1 On windows the C++ binding library does not get installed on "make install" [1]. As the C++ binding is one of the big features for 0.12 I think we should respin to fix this. Andrew [1] https://issues.apache.org/jira/browse/PROTON-1127
RFI in 0.12 PROTON-1127: Install C++ binding library correctly
Simple 1 line fix to the CMakefiles; looks bad for C++ on Windows if we don't fix this! https://issues.apache.org/jira/browse/PROTON-1127 Andrew
[jira] [Created] (PROTON-1127) [Windows] qpid-proton-cpp.dll not installed by "make install" target
Andrew Stitcher created PROTON-1127: --- Summary: [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] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-515: --- Attachment: 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch I've attached a possible fix for the OpenVMS linker problem. [~solttom] please try this on your OpenVMS system, if it works for you I'm open to getting this in Proton. > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Assignee: Andrew Stitcher > Labels: OpenVMS, patch > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, io.c.patch, > object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130551#comment-15130551 ] Andrew Stitcher commented on PROTON-515: 1) Seems like a strange platform behaviour, but I think it'll work if you follow the plan I outlined. 2) I think you have misunderstood the purpose of the statics: _PN_HANDLE_ ## name is used only used to get the compiler to allocate a unique address in the program address space. This address is then converted into an integer and used as a handle for the record type. This handle needs to be unique for the entire program even if the variable that holds it is static - that's because it is used by the logic that attaches records to events to distinguish the various record types. I think this limitation of your linker is pretty serious, because every scheme I can think of to generate this unique ids straightforwardly involves getting the linker to allocate some space in the program get its address and use that as the handle. Perhaps we could make the pn_handle_t actually use a void* as its type - that might work around the linker (as the message implied that it was converting to a non pointer type that is the issue). > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Assignee: Andrew Stitcher > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-683) Register Proton for Coverity scans
[ https://issues.apache.org/jira/browse/PROTON-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-683. Resolution: Fixed > Register Proton for Coverity scans > -- > > Key: PROTON-683 > URL: https://issues.apache.org/jira/browse/PROTON-683 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, proton-j >Reporter: Justin Ross > > For reference, the Qpid C++ and Java projects at Coverity: > https://scan.coverity.com/projects/6 > https://scan.coverity.com/projects/572 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-683) Register Proton for Coverity scans
[ https://issues.apache.org/jira/browse/PROTON-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129097#comment-15129097 ] Andrew Stitcher commented on PROTON-683: Proton is registered as: https://scan.coverity.com/projects/apache-qpid-proton > Register Proton for Coverity scans > -- > > Key: PROTON-683 > URL: https://issues.apache.org/jira/browse/PROTON-683 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, proton-j >Reporter: Justin Ross > > For reference, the Qpid C++ and Java projects at Coverity: > https://scan.coverity.com/projects/6 > https://scan.coverity.com/projects/572 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Request for inclusion 12.0: PROTON-1116: Potential infinite recursion detected by VC++14 compiler
Approved for 0.12 On Tue, 2016-02-02 at 16:09 -0500, Alan Conway wrote: > Very simple fix, potentially confusing bug. The implicit conversion > to > an excessivly lax template value ctor leads to very confusing error > messages. Fix is to make it explicit, fancy type-deduction stuff > coming > for 0.13 ;)
[jira] [Updated] (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:all-tabpanel
]
Andrew Stitcher updated PROTON-1116:
Fix Version/s: 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
> Fix For: 0.12.0
>
>
> 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<std::pair<std::basic_string<char,std::char_traits,std::allocator
> >,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] [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 ] Andrew Stitcher updated PROTON-1121: Fix Version/s: (was: 0.13.0) 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.12.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] [Resolved] (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 ] Andrew Stitcher resolved PROTON-1121. - Resolution: Fixed > 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.12.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)
RFI in 0.12 - PROTON-1121
This is a potential crashing bug detected by Coverity The fix is less than a line and I judge low risk. https://issues.apache.org/jira/browse/PROTON-1121 Andrew
[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=15129037#comment-15129037
]
Andrew Stitcher commented on PROTON-1116:
-
I approve the fix for 0.12
> 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<std::pair<std::basic_string<char,std::char_traits,std::allocator
> >,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] [Resolved] (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:all-tabpanel
]
Andrew Stitcher resolved PROTON-1116.
-
Resolution: Fixed
Fixed although Alan wants to provide a better solution for 0.13
> 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
> Fix For: 0.12.0
>
>
> 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<std::pair<std::basic_string<char,std::char_traits,std::allocator
> >,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] [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 ] Andrew Stitcher updated PROTON-1121: Fix Version/s: 0.13.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] [Created] (PROTON-1124) Small problems detected by Coverity scanner
Andrew Stitcher created PROTON-1124: --- Summary: Small problems detected by Coverity scanner Key: PROTON-1124 URL: https://issues.apache.org/jira/browse/PROTON-1124 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Priority: Minor Some minor problems detected in proton-c by Coverity scan of Jan 31 2016 master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-733) SASL related updates (wishes)
[
https://issues.apache.org/jira/browse/PROTON-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-733.
Resolution: Not A Problem
Fix Version/s: 0.9
The reporter seems to say that this is no longer a problem.
> SASL related updates (wishes)
> -
>
> Key: PROTON-733
> URL: https://issues.apache.org/jira/browse/PROTON-733
> Project: Qpid Proton
> Issue Type: Wish
> Components: proton-c
>Affects Versions: 0.8
>Reporter: German Shepherd (PrE)
>Priority: Minor
> Fix For: 0.9
>
>
> Let me add a another set of SASL-related 'wishes':
> I'm running ProtonC on a memory constrained environment.
> After the SSL is connected, then there is a SASL PLAIN auth taking place.
> After the SASL is done doing its thing, it is basically not required any more
> (not until the whole connection is dropped and then reopened - this is my
> case).
> So after the dispatch of
> {{0 <- sasl-outcome(68) [ code=0, additional-data=b"Welcome!" ]}}
> I would like to have the SASL to release all its dynamic memory (the whole
> object) and remove itself from {{transport->io_layers[ PN_IO_SASL ];}}
> (replace SASL I/O functions with a pass-through functions).
> This way, there is a very welcome drop of use of the dynamic memory, as the
> actual test of this approach shows.
> As a another wish, I would like to get a new global flag (or better yet, a
> pn_xxx callback function) added, which the application can query, to see when
> the SASL is done - this is somehow crucial for timing of the behavior of the
> user application in a memory constrained environment (e.g. do not proceed
> with message memory allocations until the connection and SASL is actually
> done).
> Perhaps a better approach might be possible here (so far this particular way
> worked well), I'm all ears.
> I understand that none of the both request do apply for the 'normal' use of
> the ProtonC (where dynamic memory is not the limitation), but yet I would
> like to have the option, even if delimited with a {{#ifdef}} configuration.
> The amount of work to do this is minimal, yet I would like to get this
> discussed and done the official way,
> so I won't need to manually update the ProtonC code after downloading it.
> thx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-644) Posix driver swallows connect errors.
[ https://issues.apache.org/jira/browse/PROTON-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-644. Resolution: Resolved I think that this issue is rendered irrelevant by subsequent work. If not it can be raised again. > Posix driver swallows connect errors. > - > > Key: PROTON-644 > URL: https://issues.apache.org/jira/browse/PROTON-644 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Marcel Meulemans >Priority: Minor > Attachments: connect.patch > > > The majority of errors that can occur on a call to connect(...) (timeout, > host unreachable, network unavailable, etc) are hidden by the io layer. The > reason being that the socket is set to non-blocking prior to the call to > connect and the result of the connect is never checked. > A possible fix can be found here: > https://github.com/marcelmeulemans/qpid-proton/commit/d62cc2f482d083236512dd2a6ab93f9c85decf37 > This fix make the pn_connect function block by using select to check the > result of connect with a timeout (currently 10 sec). Another option would be > to be to set the socket to non blocking after the connect, but this can can > cause connect to block for minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-649) pn_data_vfill buffer read overflow on input beginning with '['
[
https://issues.apache.org/jira/browse/PROTON-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129201#comment-15129201
]
Andrew Stitcher commented on PROTON-649:
This was fixed by [~dnwe] in commit dddfde20 last year. - looks like it went
into 0.10.
> pn_data_vfill buffer read overflow on input beginning with '['
> --
>
> Key: PROTON-649
> URL: https://issues.apache.org/jira/browse/PROTON-649
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7, 0.8
>Reporter: Sahir Hoda
> Labels: patch
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> If the first character of the format string passed to pn_data_vfill is '[',
> the function will access memory at one byte preceding the format buffer. This
> is due to the following check:
> {code}
> case '[':
> if (*(fmt - 2) != 'T') {
> {code}
> if the format character is '[', the memory location preceding the format
> character is read. If the string begins with '[', however, this read is
> invalid.
> I didn't test with proton-0.8, but it appears from code review that the issue
> exists there as well.
> The following patch protects against the invalid memory access:
> {code}
> --- a/proton-c/src/codec/codec.c
> +++ b/proton-c/src/codec/codec.c
> @@ -467,6 +467,7 @@ int pn_data_intern_node(pn_data_t *data, pni_node_t *node)
> int pn_data_vfill(pn_data_t *data, const char *fmt, va_list ap)
> {
>int err;
> + const char * orig_fmt = fmt;
>while (*fmt) {
> char code = *(fmt++);
> if (!code) return 0;
> @@ -568,7 +569,7 @@ int pn_data_vfill(pn_data_t *data, const char *fmt,
> va_list ap)
>}
>break;
> case '[':
> - if (*(fmt - 2) != 'T') {
> + if ((fmt == (orig_fmt + 1)) || *(fmt - 2) != 'T') {
> err = pn_data_put_list(data);
> if (err) return err;
> pn_data_enter(data);
> {code}
> I ran into this issue while testing with AddressSanitizer
> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer), here is
> the relevant output:
> {noformat}
> =
> ==15828==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x7f260637315f at pc 0x7f26062eb6d6 bp 0x7f2602fdaaa0 sp 0x7f2602fdaa98
> READ of size 1 at 0x7f260637315f thread T23
> #0 0x7f26062eb6d5 in pn_data_vfill
> qpid-proton/proton-c/src/codec/codec.c:573
> #1 0x7f26062ecabd in pn_data_fill
> qpid-proton/proton-c/src/codec/codec.c:667
> #2 0x7f2606319655 in pni_disposition_encode
> qpid-proton/proton-c/src/transport/transport.c:384
> #3 0x7f26063267de in pn_post_disp
> qpid-proton/proton-c/src/transport/transport.c:1392
> #4 0x7f2606328ddc in pn_process_tpwork_receiver
> qpid-proton/proton-c/src/transport/transport.c:1488
> #5 0x7f2606329319 in pn_process_tpwork
> qpid-proton/proton-c/src/transport/transport.c:1521
> #6 0x7f260632ad8e in pn_phase
> qpid-proton/proton-c/src/transport/transport.c:1693
> #7 0x7f260632ae71 in pn_process
> qpid-proton/proton-c/src/transport/transport.c:1711
> #8 0x7f260632b50e in pn_output_write_amqp
> qpid-proton/proton-c/src/transport/transport.c:1760
> #9 0x7f260632d26b in pn_io_layer_output_passthru
> qpid-proton/proton-c/src/transport/transport.c:1973
> #10 0x7f260632d26b in pn_io_layer_output_passthru
> qpid-proton/proton-c/src/transport/transport.c:1973
> #11 0x7f260632bf04 in transport_produce
> qpid-proton/proton-c/src/transport/transport.c:1802
> #12 0x7f260632e119 in pn_transport_pending
> qpid-proton/proton-c/src/transport/transport.c:2076
> #13 0x7f26063591f0 in pn_connector_process
> qpid-proton/proton-c/src/posix/driver.c:507
> ...
> 0x7f260637315f is located 52 bytes to the right of global variable '*.LC6'
> from 'qpid-proton/proton-c/src/transport/transport.c' (0x7f2606373120) of
> size 11
> '*.LC6' is ascii string '[?DL[sSC]]'
> 0x7f260637315f is located 1 bytes to the left of global variable '*.LC7' from
> 'qpid-proton/proton-c/src/transport/transport.c' (0x7f2606373160) of size 6
> '*.LC7' is ascii string '[ooC]'
> SUMMARY: AddressSanitizer: global-buffer-overflow
> qpid-proton/proton-c/src/codec/codec.c:573 pn_data_vfill
> Shadow bytes around the buggy address:
> 0x0fe540c665d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe540c665e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe540c665f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
[jira] [Assigned] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-515: -- Assignee: Andrew Stitcher > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Assignee: Andrew Stitcher > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: JIRA 515 and release 0.12.0
On Tue, 2016-02-02 at 11:46 +, Robbie Gemmell wrote: > Andrew/Alan/Any-other-C-inclined-folks, can you look at this? I've looked at it and commented at some length in the bug report itself. > > I know a large sticking point is likely to be that we probably have > no > easy way to test things on OpenVMS, but as it seems quite contained > (though perhaps not in the desired style?) I think approaching it on > a > 'if it doesn't break anything else' basis would do fine. My major problem is that I don't understand why the change is necessary - it doesn't on the face of it seem necessary at all. I did find a related quesion on stackoverflow also from Tomas, but actually linking it to the Jira might have been of some use. Andrew
[jira] [Created] (PROTON-1121) Zero pointer derefence in pn_sasl_allowed_mechs()
Andrew Stitcher created PROTON-1121: --- Summary: 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 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] [Updated] (PROTON-855) Add axTLS (embedded SSL) support to proton-c
[ https://issues.apache.org/jira/browse/PROTON-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-855: --- Fix Version/s: (was: 0.12.0) > Add axTLS (embedded SSL) support to proton-c > > > Key: PROTON-855 > URL: https://issues.apache.org/jira/browse/PROTON-855 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: Platform independent >Reporter: Tomasz Nowicki > Assignee: Andrew Stitcher > Labels: features > Attachments: axtls.c, axtls_proton_example.c, qpidproton-AXTLS.patch, > ssl_io.h > > Original Estimate: 0h > Remaining Estimate: 0h > > The axTLS embedded SSL project is a highly configurable client/server > TLSv1 SSL library designed for platforms with small memory requirements. > It comes with a small HTTP/HTTPS server and additional test tools. > axTLS It's free! (BSD style licensing) > http://axtls.sourceforge.net/ > axTLS integration with proton is done on socket layer(posix layer). On the > other hand OpenSSL integration with proton is done on the transport layer. To > use both solutions we had to add two methods pn_ssl_recv i pn_ssl_send > (daclared in include/ssl_io.h) which in openssl mode, without crypting, > invoke native proton "pn_send" and "pn_receive (io.c)". In axTLS mode, those > methods are replaced with proper axtls comunication methods. Those are > defined in openssl.c, ssl_stub.c, axtls.c and located in src/ssl. > Methods pn_ssl_recv and pn_ssl_send replace original pn_send and pn_recv used > in pni_connection_writable(pn_selectable_t *sel), > pni_connection_readable(pn_selectable_t *sel) (connection.c). > Moreover we introduced new file axtls.c located in src/ssl. The file is an > equivalent of openssl.c, implementing base ssl methods: PN_EXTERN > pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t mode); > PN_EXTERN void pn_ssl_domain_free( pn_ssl_domain_t *domain ); etc > Example of axTLS integration with ex ActiveMQ > atatched(axtls_proton_example.c): > It's based on > http://mail-archives.us.apache.org/mod_mbox/qpid-proton/201501.mbox/%3ccacl1bnc5jerbnikd_4fgkjqh13h5nl_2z-sszp3jg2t+ywa...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [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=15126724#comment-15126724 ] Andrew Stitcher commented on PROTON-1118: - I approve this for 0.12 - very small fix, low risk fix, that works for me! > 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 > 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] [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=15123806#comment-15123806 ] Andrew Stitcher commented on PROTON-1114: - I don't deeply understand this code, but the active change looks good. I particularly like that this change mostly introduces new tests! Approved for inclusion in 0.12 > [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)
Re: Request for inclusion in 0.12.0
I've approved both of these for inclusion (in the JIRAs). Andrew On Thu, 2016-01-28 at 11:04 +, Robbie Gemmell wrote: > Hi Justin, > > I'd like to request the following for inclusion in 0.12.0: > > Stop the proton-j transport from erroneously emitting various frame > types after a Close was sent. > https://issues.apache.org/jira/browse/PROTON-1114 > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bcd08cc > > Some minor readme/pom changes around describing running the python > tests. > https://issues.apache.org/jira/browse/PROTON-1113 > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f11723c > > Thanks, > Robbie
[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=15123804#comment-15123804 ] Andrew Stitcher commented on PROTON-1113: - Approved for inclusion in 0.12 > 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] [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
]
Andrew Stitcher updated PROTON-1055:
Fix Version/s: 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.12.0, 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=15121765#comment-15121765 ] Andrew Stitcher commented on PROTON-1095: - No specific reason - only that it hasn't gone through the review/approval process for 0.12. Would you like to propose it for 0.12? > 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)
Re: Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.
On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote: > The 0.12.x branch does not compile under c++11 (clang and gcc) with > warnings, this fixes them > > https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19ab7 > c8 > 08ad43bd39274e Unfortunately this breaks windows builds - I'm working up a fix that works everywhere. Andrew
Re: Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.
On Thu, 2016-01-28 at 13:29 -0500, Andrew Stitcher wrote: > On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote: > > The 0.12.x branch does not compile under c++11 (clang and gcc) with > > warnings, this fixes them > > > > https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19a > > b7 > > c8 > > 08ad43bd39274e > > Unfortunately this breaks windows builds - I'm working up a fix that > works everywhere. I'ved worked up a somewhat improved fix that works on Windows. Because the final result is a squach of 3 changes, but it actually simple in itself I've created a branch to inspect it in the apache tree. Alan, check out astitcher/0.12.x/potential-fix [simgle change] and tell me if you think it's good. Justin, approve if Alan doesn't dissent? Andrew > > Andrew >
[jira] [Created] (PROTON-1116) Potential infinite recursion detected by VC++14 compiler
Andrew Stitcher created PROTON-1116:
---
Summary: 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
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<std::pair<std::basic_string<char,std::char_traits,std::allocator
>,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-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=15122327#comment-15122327
]
Andrew Stitcher commented on PROTON-1116:
-
Also produces the warning on VC10
> 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<std::pair<std::basic_string<char,std::char_traits,std::allocator
> >,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] [Updated] (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:all-tabpanel
]
Andrew Stitcher updated PROTON-1116:
Environment: Visual Studio 2015 Update 1, Visual Studio 2010 (was: Visual
Studio 2015 Update 1)
> 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<std::pair<std::basic_string<char,std::char_traits,std::allocator
> >,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] [Comment Edited] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120191#comment-15120191 ] Andrew Stitcher edited comment on PROTON-1095 at 1/28/16 3:36 PM: -- Currently some of this change is in 0.12, but all is in 0.13. Hopefully the balance of the change will be approved for 0.12 *Update* All of this change is now in 0.12 (except for the related connection_engine change from Alan) was (Author: astitcher): Currently some of this change is in 0.12, but all is in 0.13. Hopefully the balance of the change will be approved for 0.12 > 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] [Resolved] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1095. - Resolution: Fixed > 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.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] [Updated] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1095: Fix Version/s: 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.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] [Comment Edited] (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=15118021#comment-15118021
]
Andrew Stitcher edited comment on PROTON-1055 at 1/27/16 8:53 PM:
--
Note for the purposes of reproducing this problem the the version of ActiveMQ
tested that shouldn't accept the SASL behaviour noted is 5.12.0
was (Author: astitcher):
Note for the purposes of reproducing this problem the last version of ActiveMQ
that shouldn't accept the SASL behaviour noted is 5.12.1
> 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
>
> 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] [Resolved] (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
]
Andrew Stitcher resolved PROTON-1055.
-
Resolution: Fixed
Fix Version/s: 0.13.0
This fix has been tested against ActiveMQ 5.12.0 both with cyrus sasl and with
the default sasl provider.
ActiveMQ 5.12.0 now seems to have no problems with proton-c SASL PLAIN
authentication.
> 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)
RFI: PROTON-1055 (SASL Plain authentication can fail on some brokers)
This [1] is really an interop bug, but I suspect it will be annoying to anyone using earlier versions of ActiveMQ. The fix is pretty small and seems low risk to me. Andrew [1] https://issues.apache.org/jira/browse/PROTON-1055
[jira] [Resolved] (PROTON-1101) Proton build broken on Visual Studio 10
[
https://issues.apache.org/jira/browse/PROTON-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1101.
-
Resolution: Fixed
Assignee: (was: Cliff Jansen)
Fix Version/s: 0.12.0
This was fixed by aconway in git change:
e39baba53694f1d82e86d7909b6a8619b39d44b5
> Proton build broken on Visual Studio 10
> ---
>
> Key: PROTON-1101
> URL: https://issues.apache.org/jira/browse/PROTON-1101
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.12.0
> Reporter: Andrew Stitcher
>Priority: Blocker
> Fix For: 0.12.0
>
>
> Getting an error message:
> {noformat}
> 7>ClCompile:
> Compiling...
> connection_engine.cpp
> error.cpp
> event.cpp
> link.cpp
> link_options.cpp
> 7>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(740):
> error C2593: 'operator !=' is ambiguous
> [C:\Jenkins\jobs\proton-master-vs10-win32\workspace\bld-trunk\proton-c\bindings\cpp\qpid-proton-cpp.vcxproj]
> c:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\include\xmemory(268): could be 'bool std::operator
> !=<std::pair<_Ty1,_Ty2>,std::pair<_Ty1,_Ty2>>(const std::allocator<_Ty>
> &,const std::allocator<_Ty> &) throw()'
> with
> [
> _Ty1=const std::string,
> _Ty2=proton::scalar,
> _Ty=std::pair
> ]
>
> C:\Jenkins\jobs\proton-master-vs10-win32\workspace\src\proton-c\bindings\cpp\include\proton/types.hpp(88):
> or 'bool proton::operator !=<std::allocator<_Ty>>(const T &,const T
> &)' [found using argument-dependent lookup]
> with
> [
> _Ty=std::pair,
> T=std::allocator<std::pair std::string,proton::scalar>>
> ]
> while trying to match the argument list
> '(std::allocator<_Ty>, std::allocator<_Ty>)'
> with
> [
> _Ty=std::pair
> ]
> c:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\include\xtree(737) : while compiling class template member function
> 'void std::_Tree<_Traits>::_Assign_rv(std::_Tree<_Traits> &&)'
> with
> [
>
> _Traits=std::_Tmap_traits<std::string,proton::scalar,std::less,std::allocator<std::pair std::string,proton::scalar>>,false>
> ]
> c:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\include\map(81) : see reference to class template instantiation
> 'std::_Tree<_Traits>' being compiled
> with
> [
>
> _Traits=std::_Tmap_traits<std::string,proton::scalar,std::less,std::allocator<std::pair std::string,proton::scalar>>,false>
> ]
>
> C:\Jenkins\jobs\proton-master-vs10-win32\workspace\src\proton-c\bindings\cpp\include\proton/message.hpp(243)
> : see reference to class template instantiation 'std::map<_Kty,_Ty>' being
> compiled
> with
> [
> _Kty=std::string,
> _Ty=proton::scalar
> ]
> messaging_adapter.cpp
> {noformat}
--
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 ] Andrew Stitcher updated PROTON-1095: Fix Version/s: 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-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120191#comment-15120191 ] Andrew Stitcher commented on PROTON-1095: - Currently some of this change is in 0.12, but all is in 0.13. Hopefully the balance of the change will be approved for 0.12 > 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-1043) Possible typo in messenger.c
[
https://issues.apache.org/jira/browse/PROTON-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120195#comment-15120195
]
Andrew Stitcher commented on PROTON-1043:
-
This may be the same issue as PROTON-988 (at least its closely related)
> 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] [Resolved] (PROTON-247) provide configuration for messenger to disable sasl layer
[ https://issues.apache.org/jira/browse/PROTON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-247. Resolution: Unresolved This issue relates to a much earlier version of proton. The SASL implementation has moved on, and it's not clear this issue is relevant any more. > provide configuration for messenger to disable sasl layer > - > > Key: PROTON-247 > URL: https://issues.apache.org/jira/browse/PROTON-247 > Project: Qpid Proton > Issue Type: New Feature >Reporter: Rafael H. Schloming > Labels: messenger > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Request for inclusion in 0.12 beta
I've now checked in the working version of the improved error work [1] to master, and I'd like to check it in to 0.12. The missing commits are: 80587567cc1c48e25fd69a6175667471e7c8 fa11ada8a804c2353633965ff756b9c5991d1cc6 9d3e995393a918b80aca5ef60061b27a387d053d f066bd520cb2b43524c0e836ee8e8b93e5384c7f Andrew [1] https://issues.apache.org/jira/browse/PROTON-1095
[jira] [Resolved] (PROTON-1108) Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce TRANSPORT_ERROR event
[ https://issues.apache.org/jira/browse/PROTON-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1108. - Resolution: Fixed > Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce > TRANSPORT_ERROR event > - > > Key: PROTON-1108 > URL: https://issues.apache.org/jira/browse/PROTON-1108 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding > Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Request for inclusion in 0.12 beta
I mean request for inclusion in 0.12 - the beta has already branched! On Tue, 2016-01-26 at 15:35 -0500, Andrew Stitcher wrote: > I've now checked in the working version of the improved error work > [1] > to master, and I'd like to check it in to 0.12. > > The missing commits are: > > 80587567cc1c48e25fd69a6175667471e7c8 > fa11ada8a804c2353633965ff756b9c5991d1cc6 > 9d3e995393a918b80aca5ef60061b27a387d053d > f066bd520cb2b43524c0e836ee8e8b93e5384c7f > > Andrew > > [1] https://issues.apache.org/jira/browse/PROTON-1095 > >
[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=15118021#comment-15118021
]
Andrew Stitcher commented on PROTON-1055:
-
Note for the purposes of reproducing this problem the last version of ActiveMQ
that shouldn't accept the SASL behaviour noted is 5.12.1
> 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
>
> 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] [Created] (PROTON-1108) Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce TRANSPORT_ERROR event
Andrew Stitcher created PROTON-1108: --- Summary: Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce TRANSPORT_ERROR event Key: PROTON-1108 URL: https://issues.apache.org/jira/browse/PROTON-1108 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.12.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1101) Proton build broken on Visual Studio 10
Andrew Stitcher created PROTON-1101:
---
Summary: Proton build broken on Visual Studio 10
Key: PROTON-1101
URL: https://issues.apache.org/jira/browse/PROTON-1101
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Affects Versions: 0.12.0
Reporter: Andrew Stitcher
Assignee: Cliff Jansen
Priority: Blocker
Getting an error message:
{noformat}
7>ClCompile:
Compiling...
connection_engine.cpp
error.cpp
event.cpp
link.cpp
link_options.cpp
7>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(740):
error C2593: 'operator !=' is ambiguous
[C:\Jenkins\jobs\proton-master-vs10-win32\workspace\bld-trunk\proton-c\bindings\cpp\qpid-proton-cpp.vcxproj]
c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\xmemory(268): could be 'bool std::operator
!=<std::pair<_Ty1,_Ty2>,std::pair<_Ty1,_Ty2>>(const std::allocator<_Ty> &,const
std::allocator<_Ty> &) throw()'
with
[
_Ty1=const std::string,
_Ty2=proton::scalar,
_Ty=std::pair
]
C:\Jenkins\jobs\proton-master-vs10-win32\workspace\src\proton-c\bindings\cpp\include\proton/types.hpp(88):
or 'bool proton::operator !=<std::allocator<_Ty>>(const T &,const T &)'
[found using argument-dependent lookup]
with
[
_Ty=std::pair,
T=std::allocator<std::pair>
]
while trying to match the argument list '(std::allocator<_Ty>,
std::allocator<_Ty>)'
with
[
_Ty=std::pair
]
c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\xtree(737) : while compiling class template member function
'void std::_Tree<_Traits>::_Assign_rv(std::_Tree<_Traits> &&)'
with
[
_Traits=std::_Tmap_traits<std::string,proton::scalar,std::less,std::allocator<std::pair>,false>
]
c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\map(81) : see reference to class template instantiation
'std::_Tree<_Traits>' being compiled
with
[
_Traits=std::_Tmap_traits<std::string,proton::scalar,std::less,std::allocator<std::pair>,false>
]
C:\Jenkins\jobs\proton-master-vs10-win32\workspace\src\proton-c\bindings\cpp\include\proton/message.hpp(243)
: see reference to class template instantiation 'std::map<_Kty,_Ty>' being
compiled
with
[
_Kty=std::string,
_Ty=proton::scalar
]
messaging_adapter.cpp
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Please update appveyor.yml version [Was: Proton 0.12.0 release update - Alpha is available]
A small request for the release manager: could you please add updating the appveyor.yml file to the correct version to the release process. I've just noticed that the appveyor build still thinks the build version is 0.10-SNAPSHOT. This strongly implies that the master appveyor.yml has not been updated in 2 releases. This is not terrible, but it is a bit confusing when you go to the appveyor website and see status of our builds. [I've update master to 0.12-SNAPSHOT now, but the beta branch will need updating to 0.12 and the master branch to 0.13-SNAPSHOT or whatever we call the next release of proton] Thanks Andrew On Wed, 2016-01-13 at 17:21 -0800, Justin Ross wrote: > Hello, everyone. It's time for the Proton 0.12.0 alpha. > > Revision: 576f656b on master > Artifacts: > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-alpha/ > Test output: > http://people.apache.org/~jross/qpid-releases/quirk-proton-0.12.0-alp > ha.log > > See the release page[1] for more information about the schedule and > criteria for accepting changes. > > We branch for release in *one week*. Start your testing early. > > Thanks! > Justin > > --- > [1] Proton 0.12.0 release page: > https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.12.0
[jira] [Commented] (PROTON-855) Add axTLS (embedded SSL) support to proton-c
[ https://issues.apache.org/jira/browse/PROTON-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094517#comment-15094517 ] Andrew Stitcher commented on PROTON-855: This seems implemented a little strangely: AxTLS essentially replaces the lower level socket send/recv so when using it in effect you don't have a proton SSL/TLS layer at all. The Proton layer design assumes that each layer is an engine that you can feed bytes into at the bottom and take transformed bytes out of the top for reading (and vice versa for writing). AXTLS gives you no access to bytes in/out the bottom (afaict) and goes straight to the sockets API itself. If you use an API like this you can't fit it into the layer design. I think the mixed design you have here would work extremely badly with the server side protocol auto detection code which sets up the layers automatically. Using an SSL/TLS API such as this is possible, but I don't think the way to do it is quite like this. You would need to do all of the SSL work in the io layer and proton would be entirely unawar that there was any encryption happening. > Add axTLS (embedded SSL) support to proton-c > > > Key: PROTON-855 > URL: https://issues.apache.org/jira/browse/PROTON-855 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: Platform independent >Reporter: Tomasz Nowicki > Assignee: Andrew Stitcher > Labels: features > Fix For: 0.12.0 > > Attachments: axtls.c, axtls_proton_example.c, qpidproton-AXTLS.patch, > ssl_io.h > > Original Estimate: 0h > Remaining Estimate: 0h > > The axTLS embedded SSL project is a highly configurable client/server > TLSv1 SSL library designed for platforms with small memory requirements. > It comes with a small HTTP/HTTPS server and additional test tools. > axTLS It's free! (BSD style licensing) > http://axtls.sourceforge.net/ > axTLS integration with proton is done on socket layer(posix layer). On the > other hand OpenSSL integration with proton is done on the transport layer. To > use both solutions we had to add two methods pn_ssl_recv i pn_ssl_send > (daclared in include/ssl_io.h) which in openssl mode, without crypting, > invoke native proton "pn_send" and "pn_receive (io.c)". In axTLS mode, those > methods are replaced with proper axtls comunication methods. Those are > defined in openssl.c, ssl_stub.c, axtls.c and located in src/ssl. > Methods pn_ssl_recv and pn_ssl_send replace original pn_send and pn_recv used > in pni_connection_writable(pn_selectable_t *sel), > pni_connection_readable(pn_selectable_t *sel) (connection.c). > Moreover we introduced new file axtls.c located in src/ssl. The file is an > equivalent of openssl.c, implementing base ssl methods: PN_EXTERN > pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t mode); > PN_EXTERN void pn_ssl_domain_free( pn_ssl_domain_t *domain ); etc > Example of axTLS integration with ex ActiveMQ > atatched(axtls_proton_example.c): > It's based on > http://mail-archives.us.apache.org/mod_mbox/qpid-proton/201501.mbox/%3ccacl1bnc5jerbnikd_4fgkjqh13h5nl_2z-sszp3jg2t+ywa...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-852) Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support getaddrinfo(),getprotobyname()
[ https://issues.apache.org/jira/browse/PROTON-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094423#comment-15094423 ] Andrew Stitcher commented on PROTON-852: What version of uclibc are you using? UClibs seems to have supported getaddrinfo and friends since 2002 (from the git records). Perhaps you could reconfigure your uclibc build to include these functions if they are not included? I'm not dismissing this feature request, but on the whole we are targeting POSIX and Windows environments. getaddinfo() and friends are now pretty universally available where a BSD sockets like interface is available. If that really isn't possible (perhaps the uclibc build isn't under your control) this should be implemented by creating a new "platform" - cramming this into the "posix" platform is plain wrong since posix really does support the getaddrinfo etc. interfaces. As a first cut call it something like "uclibc-minimal". In this case it seems you could reuse the existing src/posix/ code but add a new directory src/uclibc-minimal/ for the extra code you need to implement getaddrinfo etc. Then detect/configure your specific configuration in cmake and add in the new file(s) to the build. Incidentally I pretty sure you can't include in platform.h because this just defines the platform API but is not platform specific. arpa/int.h is only supported on POSIX. > Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support > getaddrinfo(),getprotobyname() > - > > Key: PROTON-852 > URL: https://issues.apache.org/jira/browse/PROTON-852 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: uclinux m68k > Reporter: Tomasz Nowicki >Assignee: Andrew Stitcher > Labels: patch > Fix For: 0.12.0 > > Attachments: proton-c-GETADDRINFO.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > We are using proton-c on a small ebedded system based on uclinux/uclibc.c On > this platform several required functions ex getaddrinfo(), getprotobyname() > are not implemented.We added support for this type of platform by wraping > with pn_getaddrinfo,pn_getprotobyname. Relevant pn_freeaddrinfo is also > introduced. If GETADDRINFO_NOT_IMPL flag is not present, native > implementation is called. Changes apply for posix versions that use old lib.c > Specifically in some embedded versions "get host" is not present(ip address > is used instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-909) Tests for new SASL features and mechanisms
[ https://issues.apache.org/jira/browse/PROTON-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher closed PROTON-909. -- Resolution: Fixed > Tests for new SASL features and mechanisms > -- > > Key: PROTON-909 > URL: https://issues.apache.org/jira/browse/PROTON-909 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c > Reporter: Andrew Stitcher > Assignee: Andrew Stitcher > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1095) Error handling
Andrew Stitcher created PROTON-1095: --- Summary: 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 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] [Resolved] (PROTON-626) Add CMake build output files to gitignore
[
https://issues.apache.org/jira/browse/PROTON-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-626.
Resolution: Won't Fix
Building using CMake is not intended to be done in the source directory.
Please create a new directory for the build and run cmake there.
> Add CMake build output files to gitignore
> -
>
> Key: PROTON-626
> URL: https://issues.apache.org/jira/browse/PROTON-626
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Affects Versions: 0.7
> Environment: CentOS 6.5
>Reporter: Teerapap Changwichukarn
>Priority: Minor
> Attachments: 0001-qpid-proton-Ignore-CMake-output-files.patch
>
>
> I run these commands below.
> {{cmake . -DCMAKE_INSTALL_PREFIX=build -DNOBUILD_JAVA=ON
> -DSYSINSTALL_BINDINGS=OFF}}
> {{make all}}
> There are some build output files from this command. I think they should be
> in gitignore.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
