[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
> "
> line 992, in test_client_credentials
> self.server.subscribe("amqps://~0.0.0.0:12345")
> File
> "
> line 496, in subscribe
> self._check(pn_error_code(pn_messenger_error(self._mng)))
> File
> "
> 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
"
line 992, in test_client_credentials
self.server.subscribe("amqps://~0.0.0.0:12345")
File
"
line 496, in subscribe
self._check(pn_error_code(pn_messenger_error(self._mng)))
File
"
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 -> @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"}]
>
[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) [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]:
[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)
[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-1126) Allow setting connection properties in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-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] [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=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] [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] [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] [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)
[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] [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=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] [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=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=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] [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] [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=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)
