[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] [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-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] [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] [Created] (PROTON-1178) [C++ binding] Rearrange delivery class
Andrew Stitcher created PROTON-1178: --- Summary: [C++ binding] Rearrange delivery class Key: PROTON-1178 URL: https://issues.apache.org/jira/browse/PROTON-1178 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher * Rename {{delivery}} to {{transfer}} and make it the parent class for ** {{tracker}} - to track message transfers from sender ** {{delivery}} - to manage message delivery at the receiver * Split old {{delivery}} methods appropriately between {{transfer}}, {{tracker}} & {{delivery}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 resolved PROTON-1135. - Resolution: Fixed Fix Version/s: 0.13.0 > [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 > Fix For: 0.13.0 > > > 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&focusedCommentId=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] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login
[ https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228403#comment-15228403 ] Andrew Stitcher commented on PROTON-1136: - I've now checked in a fix for the related JIRA PROTON-1135. So proton-c no longer generates pipelined SASL and AMQP frames. I have modified the python based tests to carry on testing that the proton implementation accepts pipelined SASL and AMQP frames. However due to this bug Proton-J would fail this test, so I've disabled it for testing Proton-J (as it isn't a regression). The test is proton_tests.sasl.SaslTest.testPipelinedClient currently this is disabled on line 107 of tests/python/proton_tests/sasl.py. When this bug if fixed this test should be enabled for Java. > [proton-j] handle the case when pipelined SASL and OPEN frames are sent for > ANONYMOUS login > --- > > Key: PROTON-1136 > URL: https://issues.apache.org/jira/browse/PROTON-1136 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Ganesh Murthy > > Currently Proton-J is unable to handle pipelined SASL and OPEN frames for > ANONYMOUS logins, which are currently sent by proton-c, e.g see the below > trace log from Dispatch connecting out using ANONYMOUS: > {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 > {code} > Given that there are various clients using proton that might do this by > default (PROTON-1135 raised regarding that), proton-j should be updated to > cope with it. -- 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&focusedCommentId=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&focusedCommentId=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] [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&focusedCommentId=15214308#comment-15214308 ] Andrew Stitcher commented on PROTON-1135: - My understanding of AMQP 1.0 (admittedly based on conversation with [~rhs] rather than detailed study of the spec) is that the "pipelined" behaviour is expected behaviour and is specifically allowed so that simple implementations that only support ANONYMOUS or PLAIN can literally marshall all the bytes to send at once, then send them with no analysis of any returning bytes. Of course you don't have to do this, but if we make not doing it the default I guarantee the code in proton-c that copes with incoming pipelined frames will stop working very quickly as it will no longer get tested, and it is amongst the most complicated protocol code in proton-c. This is largely because it has to span the different possible protocols that are on offer - ssl, sasl and amqp. So I'm highly unconvinced that this should be made default behaviour. > [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] [Created] (PROTON-1163) Allow examples to use C++11 override
Andrew Stitcher created PROTON-1163: --- Summary: Allow examples to use C++11 override Key: PROTON-1163 URL: https://issues.apache.org/jira/browse/PROTON-1163 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Cliff Jansen The C++11 override feature is extremely useful for detecting when you have the wrong signature for an overridden member function sued for an interface. As we are developing the C++ API which uses inheritance from proton::handler in exactly this way it is extremely helpful to get the compiler to find mistakes in this regard especially as the interface changes. So this change introduces override in the appropriate useful places in a way that is backward compatible with C++03 and earlier with some small limitiations (essentially you can't use the keyword "override" in your code). -- 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)
[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)
[jira] [Commented] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150849#comment-15150849 ] Andrew Stitcher commented on PROTON-515: These changes look good. Small details: Do you use cmake to build on OpenVMS? You don't seem to have added any way to select an OpenVMS build. If you use something else would you consider adding a small documentation file detailing how to build proton using OpenVMS so that someone else could benefit from your work? Is socklen_t not defined at all on OpenVMS? It is a pretty necessary part of the sockets API. I would expect it to be in . So rather than the #ifdef try just: #include which I'd prefer, if that really doesn't work then I guess the ifdef is acceptable. > 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, > CMakeLists.txt.patch, io.c.patch, pipe.c.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-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-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] [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] [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)
[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&focusedCommentId=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-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] [Resolved] (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:all-tabpanel ] Andrew Stitcher resolved PROTON-649. Resolution: Fixed Fix Version/s: 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 > Fix For: 0.10 > > 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 > 0x0fe540c66600: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 01 f9 f9 > 0x0fe540c66610: f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 00 02 f9 f9 > =>0x0fe540c66620: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9[f9]06 f9 f9 f9 > 0x0fe540c66630: f9 f9 f9 f9 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 > 0x0fe540c66640: 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 > 0x0fe54
[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&focusedCommentId=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 > 0x0fe540c66600: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 01 f9 f9 > 0x0fe540c66610: f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 00 02 f9 f9 > =>0x0fe540c66620: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9[f9]06 f9 f9 f9 > 0x0fe540c66630: f9 f9 f9 f9 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 > 0x0fe540c
[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)
[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] [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::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::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-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&focusedCommentId=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)
[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] [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&focusedCommentId=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::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] [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] [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] [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)
[jira] [Commented] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128592#comment-15128592 ] Andrew Stitcher commented on PROTON-515: I have difficulty believing that OpenVMS doesn't have the pipe call. Ah, I see from your stackoverflow question (http://stackoverflow.com/questions/32268232/c-poll-pipe-incompatibility-on-openvms) that it's somehow to do with receiving ENOTSOCK - are you sure that is coming from poll() rather than recv()? If it is from recv then we should be more careful to read it with read(). In any case if you really need to replace that io code then you need a new file as this code does not support posix anymore so the existing io.c is not the place for this change. I would suggest splitting out pn_pipe() into its own file .../posix/pipe.c and creating a new file .../openvms/pipe.c and then compiling .../openvms/pipe.c instead of .../posix/pipe.c on openvms. You will need a change to the CMake file as well to do this. The patch for object.c is bad code as it does not guarantee that the new handle will actually be unique in the process. Can you explain why the original code didn't work - it only uses C89 features of the preprocessor - there is nothing non portable about it. > 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 > 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] [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&focusedCommentId=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&focusedCommentId=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)
[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&focusedCommentId=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] [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&focusedCommentId=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::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::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] [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::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-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[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] [Comment Edited] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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)
[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&focusedCommentId=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] [Commented] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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] [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] [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>>(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 !=>(const T &,const T > &)' [found using argument-dependent lookup] > with > [ > _Ty=std::pair, > T=std::allocator 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::allocator 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::allocator 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] [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)
[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&focusedCommentId=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] [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&focusedCommentId=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] [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)
[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>>(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 !=>(const T &,const T &)' [found using argument-dependent lookup] with [ _Ty=std::pair, T=std::allocator> ] 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::allocator>,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::allocator>,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] [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&focusedCommentId=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&focusedCommentId=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] [Resolved] (PROTON-248) Subordinate CMakeLists.txt files should not build on their own
[ https://issues.apache.org/jira/browse/PROTON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-248. Resolution: Won't Fix > Subordinate CMakeLists.txt files should not build on their own > -- > > Key: PROTON-248 > URL: https://issues.apache.org/jira/browse/PROTON-248 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Affects Versions: 0.4 > Environment: Windows, perhaps all. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > If CMake is pointed to the wrong (subordinate, instead of top level) > directory, the CMakeLists.txt file should detect the problem and exit with a > clear error message instead of generating a bogus build accompanied by a > vague warning. > To reproduce: > cd trunk\proton-c > mkdir build > cd build > cmake [args] .. > [build away] > In which case cmake uses trunk/proton-c/CMakeLists.txt as the top level > instead of trunk/CMakeLists.txt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-248) Subordinate CMakeLists.txt files should not build on their own
[ https://issues.apache.org/jira/browse/PROTON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089866#comment-15089866 ] Andrew Stitcher commented on PROTON-248: I think this is intentional behaviour on the part of cmake - it is not unusual to have sub directories that have cmake build systems that are self contained and could work on their own. > Subordinate CMakeLists.txt files should not build on their own > -- > > Key: PROTON-248 > URL: https://issues.apache.org/jira/browse/PROTON-248 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Affects Versions: 0.4 > Environment: Windows, perhaps all. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > If CMake is pointed to the wrong (subordinate, instead of top level) > directory, the CMakeLists.txt file should detect the problem and exit with a > clear error message instead of generating a bogus build accompanied by a > vague warning. > To reproduce: > cd trunk\proton-c > mkdir build > cd build > cmake [args] .. > [build away] > In which case cmake uses trunk/proton-c/CMakeLists.txt as the top level > instead of trunk/CMakeLists.txt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-152) SASL architecture does not support security layers
[ https://issues.apache.org/jira/browse/PROTON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-152. Resolution: Fixed This is now implemented. > SASL architecture does not support security layers > -- > > Key: PROTON-152 > URL: https://issues.apache.org/jira/browse/PROTON-152 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross > Labels: security > > SASL can optionally insert a security layer in the data stream for a > connection. The security layer encrypts/signs/decrypts the data stream. In > this way it is architecturally similar to SSL: It performs a handshake > in-the-clear and then inserts itself into the stream to provide link security. > Without this support, mechanisms like GSSAPI (Kerberos5) cannot be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-198) Pkg config file installed in the wrong location on FreeBSD
[ https://issues.apache.org/jira/browse/PROTON-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-198: -- Assignee: Andrew Stitcher > Pkg config file installed in the wrong location on FreeBSD > -- > > Key: PROTON-198 > URL: https://issues.apache.org/jira/browse/PROTON-198 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 > Environment: FreeBSD >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > make install puts the libqpid-proton.pc file in the wrong location for the > platform: > In /usr/local//pkgconfig. This platform has a seperate > /usr/local/libdata directory for stuff like this. > This wouldn't be so bad if it could be configured, but currently the > pkgconfig directory is hardcoded to be related to the libdir. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-206) Use const char* variables for string literals
[ https://issues.apache.org/jira/browse/PROTON-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-206. Resolution: Fixed Closing old bug: I think this has been fixed., but in any case these uses would cause a type mismatch when compiling in C++. > Use const char* variables for string literals > - > > Key: PROTON-206 > URL: https://issues.apache.org/jira/browse/PROTON-206 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: all >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > > proton sometimes uses declarations of the form > char *host = "0.0.0.0"; > These should be hunted down and replaced with a const declaration. Where > these variables are passed as arguments to other functions, those should be > additionally changed to const where appropriate. This occurs in > examples/messenger/c/send.c > examples/messenger/c/recv.c > src/messenger.c > src/util.c > src/proton.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-332) SASL module needs access to the SSL module
[ https://issues.apache.org/jira/browse/PROTON-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-332. Resolution: Fixed This has been rendered entirely moot by the SASL work on PROTON-334, which implement SASL EXTERNAL. > SASL module needs access to the SSL module > -- > > Key: PROTON-332 > URL: https://issues.apache.org/jira/browse/PROTON-332 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: security > > The SASL interface needs to be extended with a function that provides a > pointer to an SSL session. This is needed because the EXTERNAL mechanism > handshake requires access to the authentication ID from the external (ssl) > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[ https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-411. Resolution: Won't Fix > [proton-c] windows cmake configures file libqpid-proton.pc with unix settings > - > > Key: PROTON-411 > URL: https://issues.apache.org/jira/browse/PROTON-411 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: windows > > Windows needs something other than hard coded > Libs: -L${libdir -lqpid-proton > Cflags: -I${includedir}} > All the other computed values configured into this file are correct: PREFIX, > EXEC_PREFIX, LIBDIR, INCLUDEDIR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[ https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089812#comment-15089812 ] Andrew Stitcher commented on PROTON-411: I think this assertion is incorrect: The pkg-config stuff is only used (and useful) for gcc (or similar compilers) not visual studio. Therefore the command liine options should be for gcc etc. and deosn't need changing. To amplify: The only sensible way to use pkg-config on Windows is under cygwin (or maybe mingw) and for that these file contents would be okay. [Or did I miss something?] > [proton-c] windows cmake configures file libqpid-proton.pc with unix settings > - > > Key: PROTON-411 > URL: https://issues.apache.org/jira/browse/PROTON-411 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: windows > > Windows needs something other than hard coded > Libs: -L${libdir -lqpid-proton > Cflags: -I${includedir}} > All the other computed values configured into this file are correct: PREFIX, > EXEC_PREFIX, LIBDIR, INCLUDEDIR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-594) In tree builds with cmake causes issues when running python based tests
[ https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-594. Resolution: Won't Fix In tree builds are not supported. CMake will do in tree builds, but they are strongly discouraged. > In tree builds with cmake causes issues when running python based tests > --- > > Key: PROTON-594 > URL: https://issues.apache.org/jira/browse/PROTON-594 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Rajith Attapattu >Assignee: Rafael H. Schloming > > If we do an in-tree build it causes path issues when trying to run the python > based tests against the java code. -- 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)
[jira] [Resolved] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-635. Resolution: Fixed Fix Version/s: 0.9 I think the problems that are mentioned in this bug have now been fixed. If not we can reopen this bug. [Or create a linked bug if an new issue is related] > PN_TRANSPORT events not generated in enough places > -- > > Key: PROTON-635 > URL: https://issues.apache.org/jira/browse/PROTON-635 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.9 > > > In writing a custom driver for Proton I noticed thatthe new events code does > not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol > header. > So a purely event driven driver is not going to send the outgoing protocol > header immediately, but is going to wait until it replies to the next frame > (open). > Also in error scenarios no PN_TRANSPORT is generated after the open/close > frames are generated. > This is going to end badly if the peer is waiting for the protocol header > before sending the open. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [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] [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)