[jira] [Resolved] (PROTON-1158) [proton-c] Some messenger SSL tests use hardcoded port number 12345
[ https://issues.apache.org/jira/browse/PROTON-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved PROTON-1158. --- Resolution: Fixed > [proton-c] Some messenger SSL tests use hardcoded port number 12345 > --- > > Key: PROTON-1158 > URL: https://issues.apache.org/jira/browse/PROTON-1158 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 > Reporter: Ganesh Murthy > Assignee: Ganesh Murthy >Priority: Minor > > A couple of tests in the MessengerSSLTests (in > tests/python/proton_tests/ssl.py) hard code the port numbers as 12345 > {code} > def test_server_credentials(self, > cert="server-certificate.pem", > key="server-private-key.pem", > password="server-password", > exception=None): > import sys > # java doesn't do validation in the same way (yet) > if exception and "java" in sys.platform: > raise Skipped() > self.server.certificate = _testpath(cert) > self.server.private_key = _testpath(key) > self.server.password = password > try: > self.server.start() > self.server.subscribe("amqps://~0.0.0.0:12345") > if exception is not None: > assert False, "expected failure did not occur" > except MessengerException: > e = sys.exc_info()[1] > if exception: > assert exception in str(e), str(e) > else: > raise e > {code} > Hard coding the port sometimes leads to errors if port 12345 is already > bound. > {code} > File "./tests/python/proton-test", line 362, in run > phase() > File > "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/tests/python/proton_tests/ssl.py";,> > line 992, in test_client_credentials > self.server.subscribe("amqps://~0.0.0.0:12345") > File > "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/proton-c/bindings/python/proton/__init__.py";,> > line 496, in subscribe > self._check(pn_error_code(pn_messenger_error(self._mng))) > File > "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/proton-c/bindings/python/proton/__init__.py";,> > line 300, in _check > raise exc("[%s]: %s" % (err, > pn_error_text(pn_messenger_error(self._mng > MessengerException: [-2]: CONNECTION ERROR (0.0.0.0:12345): bind: errno: 98 > proton_tests.ssl.MessengerSSLTests.test_client_credentials_bad_cert . fail > {code} > Remove all occurrences of hard coded ports in MessengerSSLTests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1158) [proton-c] Some messenger SSL tests use hardcoded port number 12345
Ganesh Murthy created PROTON-1158: - Summary: [proton-c] Some messenger SSL tests use hardcoded port number 12345 Key: PROTON-1158 URL: https://issues.apache.org/jira/browse/PROTON-1158 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Priority: Minor A couple of tests in the MessengerSSLTests (in tests/python/proton_tests/ssl.py) hard code the port numbers as 12345 {code} def test_server_credentials(self, cert="server-certificate.pem", key="server-private-key.pem", password="server-password", exception=None): import sys # java doesn't do validation in the same way (yet) if exception and "java" in sys.platform: raise Skipped() self.server.certificate = _testpath(cert) self.server.private_key = _testpath(key) self.server.password = password try: self.server.start() self.server.subscribe("amqps://~0.0.0.0:12345") if exception is not None: assert False, "expected failure did not occur" except MessengerException: e = sys.exc_info()[1] if exception: assert exception in str(e), str(e) else: raise e {code} Hard coding the port sometimes leads to errors if port 12345 is already bound. {code} File "./tests/python/proton-test", line 362, in run phase() File "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/tests/python/proton_tests/ssl.py";,> line 992, in test_client_credentials self.server.subscribe("amqps://~0.0.0.0:12345") File "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/proton-c/bindings/python/proton/__init__.py";,> line 496, in subscribe self._check(pn_error_code(pn_messenger_error(self._mng))) File "<http://mrg23.lab.bos.redhat.com:8080/job/proton-c-master-rhel-cxx/label=rhel7-64/ws/qpid-proton/proton-c/bindings/python/proton/__init__.py";,> line 300, in _check raise exc("[%s]: %s" % (err, pn_error_text(pn_messenger_error(self._mng MessengerException: [-2]: CONNECTION ERROR (0.0.0.0:12345): bind: errno: 98 proton_tests.ssl.MessengerSSLTests.test_client_credentials_bad_cert . fail {code} Remove all occurrences of hard coded ports in MessengerSSLTests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1155) [proton-c] Add allowed_mechs to BlockingConnection constructor
[ https://issues.apache.org/jira/browse/PROTON-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved PROTON-1155. --- Resolution: Fixed > [proton-c] Add allowed_mechs to BlockingConnection constructor > -- > > Key: PROTON-1155 > URL: https://issues.apache.org/jira/browse/PROTON-1155 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 > Reporter: Ganesh Murthy >Priority: Minor > > In the Proton Python binding, currently there is no way to pass in > allowed_mechs to BlockingConnection's constructor > BlockingConnection's constructor should take in an allowed_mechs parameter. > The Container object has a connect function > {code} > def connect(self, url=None, urls=None, address=None, handler=None, > reconnect=None, heartbeat=None, ssl_domain=None, **kwargs): > {code} > The above function already sets the allowed_mechs on the Connector > {code} > connector.allowed_mechs = kwargs.get('allowed_mechs', self.allowed_mechs) > {code} > So BlockingConnection just needs to pass in the allowed_mechs and the rest is > take care of by the Container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1155) [proton-c] Add allowed_mechs to BlockingConnection constructor
Ganesh Murthy created PROTON-1155: - Summary: [proton-c] Add allowed_mechs to BlockingConnection constructor Key: PROTON-1155 URL: https://issues.apache.org/jira/browse/PROTON-1155 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ganesh Murthy Priority: Minor In the Proton Python binding, currently there is no way to pass in allowed_mechs to BlockingConnection's constructor BlockingConnection's constructor should take in an allowed_mechs parameter. The Container object has a connect function {code} def connect(self, url=None, urls=None, address=None, handler=None, reconnect=None, heartbeat=None, ssl_domain=None, **kwargs): {code} The above function already sets the allowed_mechs on the Connector {code} connector.allowed_mechs = kwargs.get('allowed_mechs', self.allowed_mechs) {code} So BlockingConnection just needs to pass in the allowed_mechs and the rest is take care of by the Container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1140) [proton-c] Always set process name and process id as message properties
[ https://issues.apache.org/jira/browse/PROTON-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated PROTON-1140: -- Description: The connection initiating peer must set message properties of process name and process id. The receiving peer will be able to access these properties using pn_connection_remote_properties(connection) (was: The connection initiating peer must set message properties of process name and process id. The receiving peer will be able to access there properties using pn_connection_remote_properties(connection)) > [proton-c] Always set process name and process id as message properties > > > Key: PROTON-1140 > URL: https://issues.apache.org/jira/browse/PROTON-1140 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.12.0 > Reporter: Ganesh Murthy >Priority: Minor > > The connection initiating peer must set message properties of process name > and process id. The receiving peer will be able to access these properties > using pn_connection_remote_properties(connection) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1140) [proton-c] Always set process name and process id as message properties
Ganesh Murthy created PROTON-1140: - Summary: [proton-c] Always set process name and process id as message properties Key: PROTON-1140 URL: https://issues.apache.org/jira/browse/PROTON-1140 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.12.0 Reporter: Ganesh Murthy Priority: Minor The connection initiating peer must set message properties of process name and process id. The receiving peer will be able to access there properties using pn_connection_remote_properties(connection) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 ] Ganesh Murthy updated PROTON-1135: -- Description: 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 enables sending pipelined OPEN frames for ANONYMOUS logins to aid compatibility with other components. was: 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 stop enables sending pipelined OPEN frames for ANONYMOUS logins to aid compatibility with other components. > [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 -> @
[jira] [Updated] (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 ] Ganesh Murthy updated PROTON-1135: -- Description: 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 by default enables sending pipelined OPEN frames for ANONYMOUS logins to aid compatibility with other components. was: 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 enables sending pipelined OPEN frames for ANONYMOUS logins to aid compatibility with other components. > [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) [mechan
[jira] [Created] (PROTON-1136) Proton J must handle the case when pipelined SASL and OPEN frames are sent
Ganesh Murthy created PROTON-1136: - Summary: Proton J must handle the case when pipelined SASL and OPEN frames are sent 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. Proton-J should be fixed such that it handles the following scenario {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} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1135) By default the flag that allows AMQP SASL and OPEN frames to be pipelined must be turned off
Ganesh Murthy created PROTON-1135: - Summary: By default the flag that allows AMQP SASL and OPEN frames to be pipelined must be turned off 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) sends pipelined SASL and OPEN frames by default like 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} As per the AMQP 1.0 spec - the OPEN frame is sent after the SASL exchange is complete as shown below - {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 turn off the flag that enables sending pipelined OPEN frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0
+1 (non-binding) Thanks. - Original Message - From: "Justin Ross" To: us...@qpid.apache.org Cc: proton@qpid.apache.org Sent: Wednesday, February 10, 2016 10:29:49 AM Subject: Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0 Thanks, Ganesh. BTW, you can vote. When we tally up the results, we separate the binding (committer) from the non-binding votes, but we use all the votes in our decision nonetheless. On Wed, Feb 10, 2016 at 7:11 AM, Ganesh Murthy wrote: > I cannot vote but I did the following on Fedora 22 - > > 1. Downloaded and compiled the proton 0.12.0 RC3 source and ran all unit > tests (including the ones I added) successfully > 2. Made dispatch router master use Qpid Proton 0.12.0 RC 3. Ran dispatch > unit tests successfully. > 3. Made sure that the unit test for DISPATCH-200 which relies on > PROTON-1088 worked. > > Thanks. > > - Original Message - > From: "Justin Ross" > To: us...@qpid.apache.org, proton@qpid.apache.org > Sent: Wednesday, February 10, 2016 9:31:58 AM > Subject: Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0 > > The RC 3 maven repo: > > https://repository.apache.org/content/repositories/orgapacheqpid-1063 > > On Wed, Feb 10, 2016 at 6:04 AM, Justin Ross > wrote: > > > Hi, everyone. RC 2 had some embedded build output, which this RC > > removes. Apart from that removal, it has the same content as RC 2. > > > > The proposed release artifacts: > > > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/ > > > > Please indicate your vote below. If you favor releasing the 0.12.0 RC 3 > > bits as 0.12.0 GA, vote +1. If you have reason to think RC 3 is not > > ready for release, vote -1. > > > > Thanks, > > Justin > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0
I cannot vote but I did the following on Fedora 22 - 1. Downloaded and compiled the proton 0.12.0 RC3 source and ran all unit tests (including the ones I added) successfully 2. Made dispatch router master use Qpid Proton 0.12.0 RC 3. Ran dispatch unit tests successfully. 3. Made sure that the unit test for DISPATCH-200 which relies on PROTON-1088 worked. Thanks. - Original Message - From: "Justin Ross" To: us...@qpid.apache.org, proton@qpid.apache.org Sent: Wednesday, February 10, 2016 9:31:58 AM Subject: Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0 The RC 3 maven repo: https://repository.apache.org/content/repositories/orgapacheqpid-1063 On Wed, Feb 10, 2016 at 6:04 AM, Justin Ross wrote: > Hi, everyone. RC 2 had some embedded build output, which this RC > removes. Apart from that removal, it has the same content as RC 2. > > The proposed release artifacts: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/ > > Please indicate your vote below. If you favor releasing the 0.12.0 RC 3 > bits as 0.12.0 GA, vote +1. If you have reason to think RC 3 is not > ready for release, vote -1. > > Thanks, > Justin >
[jira] [Commented] (PROTON-1126) Allow setting connection properties in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131013#comment-15131013 ] Ganesh Murthy commented on PROTON-1126: --- See if you can also allow setting the offered_capabilities and desired_capabilities > Allow setting connection properties in BlockingConnection > - > > Key: PROTON-1126 > URL: https://issues.apache.org/jira/browse/PROTON-1126 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11.1 > Reporter: Ganesh Murthy >Priority: Minor > Fix For: 0.13.0 > > > The BlockingConnection class in proton/bindings/python/proton/utils.py does > not have a way to set the connection properties. > connection properties are sent as part of the AMQP open frame. > Allow the connection properties to be set on the BlockingConnection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1126) Allow setting connection properties in BlockingConnection
Ganesh Murthy created PROTON-1126: - Summary: Allow setting connection properties in BlockingConnection Key: PROTON-1126 URL: https://issues.apache.org/jira/browse/PROTON-1126 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11.1 Reporter: Ganesh Murthy Priority: Minor Fix For: 0.13.0 The BlockingConnection class in proton/bindings/python/proton/utils.py does not have a way to set the connection properties. connection properties are sent as part of the AMQP open frame. Allow the connection properties to be set on the BlockingConnection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115217#comment-15115217 ] Ganesh Murthy commented on PROTON-1088: --- Linux implementation is complete. Windows implementation is tracked via PROTON-1106 > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved PROTON-1088. --- Resolution: Fixed > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1106) Add function implementations for pn_ssl_get_cert_fingerprint and pn_ssl_get_remote_subject_subfield for Windows
Ganesh Murthy created PROTON-1106: - Summary: Add function implementations for pn_ssl_get_cert_fingerprint and pn_ssl_get_remote_subject_subfield for Windows Key: PROTON-1106 URL: https://issues.apache.org/jira/browse/PROTON-1106 Project: Qpid Proton Issue Type: Bug Reporter: Ganesh Murthy Priority: Minor Currently we have empty stubs for these methods in schannel.c The Linux side implementation using OpenSSL is already complete. The Linux implementation was done as part of PROTON-1088 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reopened PROTON-1088: --- > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved PROTON-1088. --- Resolution: Fixed Added convenience functions to obtain certificate fingerprint and subject subfields > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
Ganesh Murthy created PROTON-1088: - Summary: Add convenience functions to obtain the client certificate fingerprint, subject subfields Key: PROTON-1088 URL: https://issues.apache.org/jira/browse/PROTON-1088 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.11.1 Reporter: Ganesh Murthy Priority: Minor 1. Provide a convenience function which will return a an ssl certificate fingerprint (a sha1 or sha256 hash of the certificate). -- When you look go to a https site via a web browser, you can look at the certificate fingerprint by clicking the View Certificate button on the browser. Add a convenience function to proton which will return the char array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a 32 octet hash. The function signature should approximately look like this - void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* digest_name) 2. The subject field on the SSL cert has many subfields like - C = ISO3166 two character country code ST = state or province L = Locality; generally means city O = Organization - Company Name OU = Organization Unit - division or unit CN = CommonName - end entity name e.g. www.example.com Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1072) Proton build fails if epydoc is installed
[ https://issues.apache.org/jira/browse/PROTON-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045883#comment-15045883 ] Ganesh Murthy commented on PROTON-1072: --- The build works fine when I commented out the following lines in /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt if (EPYDOC_EXE) foreach (py_src_doc ${pysrc}) list(APPEND PY_DOC_FILES "${CMAKE_CURRENT_SOURCE_DIR}/${py_src_doc}") endforeach(py_src_doc) add_custom_target(docs-py COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../../env.py -- PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}:${CMAKE_CURRENT_SOURCE_DIR} ${EPYDOC_EXE} -v --no-private --html -o ${CMAKE_CURRENT_BINARY_DIR}/html ${PY_DOC_FILES} DEPENDENCIES ${SWIG_MODULE_${cproton}_REAL_NAME) add_dependencies(docs docs-py) install(DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/html/" DESTINATION "${PROTON_SHARE}/docs/api-py" COMPONENT documentation ${OPTIONAL_ARG}) endif (EPYDOC_EXE > Proton build fails if epydoc is installed > - > > Key: PROTON-1072 > URL: https://issues.apache.org/jira/browse/PROTON-1072 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Affects Versions: 0.11 >Reporter: Ganesh Murthy > > Steps to reproduce > Get the latest proton from master. > Install epydoc on your system (dnf -y install epydoc (I did this on Docker > using Fedora 23 environment)) > Now run the proton build > You will see the following error - > CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 > (add_custom_target): >Syntax error in cmake code at > /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 >when parsing string > ${SWIG_MODULE_${cproton}_REAL_NAME >syntax error, unexpected $end, expecting } (34) >Policy CMP0010 is not set: Bad variable reference syntax is an error. Run >"cmake --help-policy CMP0010" for policy details. Use the cmake_policy >command to set the policy and suppress this warning. > This warning is for project developers. Use -Wno-dev to suppress it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1072) Proton build fails if epydoc is installed
[ https://issues.apache.org/jira/browse/PROTON-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated PROTON-1072: -- Description: Steps to reproduce Get the latest proton from master. Install epydoc on your system (dnf -y install epydoc (I did this on Docker using Fedora 23 environment)) Now run the proton build You will see the following error - CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 (add_custom_target): Syntax error in cmake code at /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 when parsing string ${SWIG_MODULE_${cproton}_REAL_NAME syntax error, unexpected $end, expecting } (34) Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. was: Steps to reproduce Install epydoc on your system (dnf -y install epydoc) Now run the proton build You will see the following error - CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 (add_custom_target): Syntax error in cmake code at /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 when parsing string ${SWIG_MODULE_${cproton}_REAL_NAME syntax error, unexpected $end, expecting } (34) Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. > Proton build fails if epydoc is installed > - > > Key: PROTON-1072 > URL: https://issues.apache.org/jira/browse/PROTON-1072 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Affects Versions: 0.11 >Reporter: Ganesh Murthy > > Steps to reproduce > Get the latest proton from master. > Install epydoc on your system (dnf -y install epydoc (I did this on Docker > using Fedora 23 environment)) > Now run the proton build > You will see the following error - > CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 > (add_custom_target): >Syntax error in cmake code at > /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 >when parsing string > ${SWIG_MODULE_${cproton}_REAL_NAME >syntax error, unexpected $end, expecting } (34) >Policy CMP0010 is not set: Bad variable reference syntax is an error. Run >"cmake --help-policy CMP0010" for policy details. Use the cmake_policy >command to set the policy and suppress this warning. > This warning is for project developers. Use -Wno-dev to suppress it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1072) Proton build fails if epydoc is installed
Ganesh Murthy created PROTON-1072: - Summary: Proton build fails if epydoc is installed Key: PROTON-1072 URL: https://issues.apache.org/jira/browse/PROTON-1072 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.11 Reporter: Ganesh Murthy Steps to reproduce Install epydoc on your system (dnf -y install epydoc) Now run the proton build You will see the following error - CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 (add_custom_target): Syntax error in cmake code at /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 when parsing string ${SWIG_MODULE_${cproton}_REAL_NAME syntax error, unexpected $end, expecting } (34) Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proton 0.11.0 release update - Beta is available
I got down the proton 0.11 beta and ran dispatch tests and it looks good. I was specifically interested in two JIRAs that I created (which are fixed in this beta) and those fixes work as well. I am on Fedora 21. Thanks. Forwarded Message Subject: Proton 0.11.0 release update - Beta is available Date: Wed, 28 Oct 2015 06:49:13 -0400 From: Justin Ross Reply-To: proton@qpid.apache.org To: us...@qpid.apache.org , proton@qpid.apache.org Hi, everyone. The beta is now available from the following URL: https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-beta/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1047 Test output from my machine, Fedora 22 x86-64: http://people.apache.org/~jross/qpid-releases/quirk-proton-0.11.0-beta.log Take notice! We are on a compressed schedule. Alpha was one week ago, and RC is only one week away. We very much need testing and feedback on the beta release. With the beta, we've branched for release, and release-branch commits require approval. The release page[1] describes the procedure and criteria. Thanks! Justin --- [1] Proton 0.11.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.11.0
Fwd: Proton 0.11.0 release update - Beta is available
Can you please add me to this list? Thanks. - Forwarded Message - From: "Ted Ross" To: "ganesh Murthy" Sent: Wednesday, October 28, 2015 5:24:07 PM Subject: Fwd: Proton 0.11.0 release update - Beta is available Forwarded Message Subject: Proton 0.11.0 release update - Beta is available Date: Wed, 28 Oct 2015 06:49:13 -0400 From: Justin Ross Reply-To: proton@qpid.apache.org To: us...@qpid.apache.org , proton@qpid.apache.org Hi, everyone. The beta is now available from the following URL: https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-beta/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1047 Test output from my machine, Fedora 22 x86-64: http://people.apache.org/~jross/qpid-releases/quirk-proton-0.11.0-beta.log Take notice! We are on a compressed schedule. Alpha was one week ago, and RC is only one week away. We very much need testing and feedback on the beta release. With the beta, we've branched for release, and release-branch commits require approval. The release page[1] describes the procedure and criteria. Thanks! Justin --- [1] Proton 0.11.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.11.0
[jira] [Created] (PROTON-1018) Crash in pn_transport_finalize(transport.c) when logging level set to PN_TRACE_DRV
Ganesh Murthy created PROTON-1018: - Summary: Crash in pn_transport_finalize(transport.c) when logging level set to PN_TRACE_DRV Key: PROTON-1018 URL: https://issues.apache.org/jira/browse/PROTON-1018 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ganesh Murthy Priority: Minor When the logging level is set to PN_TRACE_DRV, the pn_ssl_free(transport) call ( inside the pn_transport_finalize(void *object)) logs messages. But the transport's context is prematurely freed and the logging framework that uses this context ends up crashing. Following is the backtrace from the qdrouter application- (gdb) bt #0 0x77bc05ab in qd_transport_tracer (transport=0x7fffe4011710, message=0x7fffe403b720 "SSL socket freed.") at /home/gmurthy/opensource/dispatch/src/server.c:74 #1 0x77972932 in ssl_vlog (ap=0x7fffe9b0b2f8, fmt=0x77978aad "SSL socket freed.", transport=) at /home/gmurthy/opensource/qpid-proton/proton-c/src/ssl/openssl.c:160 #2 ssl_log (transport=, fmt=fmt@entry=0x77978aad "SSL socket freed.") at /home/gmurthy/opensource/qpid-proton/proton-c/src/ssl/openssl.c:171 #3 0x7797474c in pn_ssl_free (transport=) at /home/gmurthy/opensource/qpid-proton/proton-c/src/ssl/openssl.c:793 #4 0x77961ff4 in pn_transport_finalize (object=0x7fffe4011710) at /home/gmurthy/opensource/qpid-proton/proton-c/src/transport/transport.c:616 #5 0x77952c28 in pn_class_decref (clazz=0x77b885c0 , object=0x7fffe4011710) at /home/gmurthy/opensource/qpid-proton/proton-c/src/object/object.c:97 #6 0x77960890 in pn_event_finalize (event=0x7fffe400dbc0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:212 #7 pn_event_finalize_cast (object=0x7fffe400dbc0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:257 #8 0x77952c28 in pn_class_decref (clazz=0x77b884c0 , object=0x7fffe400dbc0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/object/object.c:97 #9 0x77952e62 in pn_decref (object=) at /home/gmurthy/opensource/qpid-proton/proton-c/src/object/object.c:255 #10 0x77960a42 in pn_collector_pop (collector=collector@entry=0x7fffe40052f0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:189 #11 0x77960ac8 in pn_collector_drain (collector=0x7fffe40052f0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:56 #12 pn_collector_release (collector=0x7fffe40052f0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:118 #13 0x77960ae9 in pn_collector_free (collector=0x7fffe40052f0) at /home/gmurthy/opensource/qpid-proton/proton-c/src/events/event.c:109 #14 0x77bc28f4 in thread_run (arg=0x80b060) at /home/gmurthy/opensource/dispatch/src/server.c:720 #15 0x7772552a in start_thread () from /lib64/libpthread.so.0 #16 0x76c8722d in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935444#comment-14935444 ] Ganesh Murthy edited comment on PROTON-1006 at 9/29/15 5:01 PM: Downloaded the fix and tested it locally. In my particular use case, I am indeed doing further processing on the connection. This fix works for me. Thanks. was (Author: ganeshmurthy): This downloaded the fix and tested it locally. In my particular use case, I am indeed doing further processing on the connection. This fix works for me. Thanks. > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Ganesh Murthy >Assignee: Gordon Sim > Fix For: 0.11 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935444#comment-14935444 ] Ganesh Murthy commented on PROTON-1006: --- This downloaded the fix and tested it locally. In my particular use case, I am indeed doing further processing on the connection. This fix works for me. Thanks. > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Ganesh Murthy >Assignee: Gordon Sim > Fix For: 0.11 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14906817#comment-14906817 ] Ganesh Murthy commented on PROTON-1006: --- Did a little bit analysis on what is going on - The BlockingSender's send function (python/proton/utils.py) has a call to self.connection.wait as shown below - {code:title=utils.py|borderStyle=solid} class BlockingSender(BlockingLink): def send(self, msg, timeout=False, error_states=None): delivery = self.link.send(msg) self.connection.wait(lambda: delivery.settled, msg="Sending on sender %s" % self.link.name, timeout=timeout) bad = error_states if bad is None: bad = [Delivery.REJECTED, Delivery.RELEASED] if delivery.remote_state in bad: raise SendException(delivery.remote_state) return delivery {code} The above code in turn calls the send function in the Message class - {code:title=class Message|borderStyle=solid} def send(self, sender, tag=None): dlv = sender.delivery(tag or sender.delivery_tag()) encoded = self.encode() sender.stream(encoded) sender.advance() if sender.snd_settle_mode == Link.SND_SETTLED: dlv.settle() return dlv {code} The dlv.settle() call goes through successfully but the lambda: delivery.settled always returns False and the BlockingSender's send waits indefinetly > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 >Reporter: Ganesh Murthy >Assignee: Gordon Sim > Fix For: 0.10.1 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated PROTON-1006: -- Summary: Sending pre-settled messages over the python blocking api waits indefinetly (was: Sending pre-settled messages over the blocking api waits indefinetly) > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Ganesh Murthy > Fix For: 0.10.1 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1006) Sending pre-settled messages over the blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated PROTON-1006: -- Attachment: helloworld_blocking_presettled.py > Sending pre-settled messages over the blocking api waits indefinetly > > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Ganesh Murthy > Fix For: 0.10.1 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1006) Sending pre-settled messages over the blocking api waits indefinetly
Ganesh Murthy created PROTON-1006: - Summary: Sending pre-settled messages over the blocking api waits indefinetly Key: PROTON-1006 URL: https://issues.apache.org/jira/browse/PROTON-1006 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.10 Reporter: Ganesh Murthy Fix For: 0.10.1 Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a blocking connection (using a blocking sender) blocks indefinetly. Steps to reproduce - 1. Modify the helloworld_blocking.py (located in examples/python folder) to add an AtMostOnce() call before creating the sender (or use the attached file helloworld_blocking_presettled.py) 2. Start broker.py (located in examples/python folder) 3. Run helloworld_blocking_presettled.py You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)