[jira] [Created] (PROTON-1172) Bump the priority of reactor 'connecting' log messages down to Debug
Ken Giusti created PROTON-1172:
--
Summary: Bump the priority of reactor 'connecting' log messages
down to Debug
Key: PROTON-1172
URL: https://issues.apache.org/jira/browse/PROTON-1172
Project: Qpid Proton
Issue Type: Wish
Components: python-binding
Affects Versions: 0.12.0
Reporter: Ken Giusti
Priority: Trivial
Fix For: 0.13.0
The log messages:
./proton/reactor.py:541:logging.info("connecting to %s..." % url)
./proton/reactor.py:570:logging.info("connected to %s" %
event.connection.hostname)
should probably be bumped down to debug. The less chatty a utility module like
Reactor is the better. We should reserve >= INFO for less routine events.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1133) Proton C includes port number in AMQP Open hostname
[
https://issues.apache.org/jira/browse/PROTON-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-1133:
--
Assignee: Ken Giusti
> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
>Assignee: Ken Giusti
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb 8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16)
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b",
> hostname="photoserver:21000", channel-max=32767]
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at
> https://issues.apache.org/jira/browse/DISPATCH-214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1087) Building the library without the required SSL dependencies silently doesn't use SSL for AMQPS
[ https://issues.apache.org/jira/browse/PROTON-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1087. Resolution: Fixed Fix Version/s: 0.12.1 I believe the PROTON-1157 fix applies here as well. > Building the library without the required SSL dependencies silently doesn't > use SSL for AMQPS > - > > Key: PROTON-1087 > URL: https://issues.apache.org/jira/browse/PROTON-1087 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Environment: Python 3.4, Linux, Ubuntu. >Reporter: Javier Ruere >Assignee: Ken Giusti > Fix For: 0.12.1 > > > Debugging this was a nightmare as I took a long time to realize what was > actually happening. > I'd prefer a full error when trying to use the library without SSL. > If that's not possible, at least it should fail when trying to use AMQPS. > IMHO, of course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1157. Resolution: Fixed Assignee: Ken Giusti (was: Gordon Sim) > Reactor sends messages in the clear if ssl is requested by not available. > - > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.13.0 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
[ https://issues.apache.org/jira/browse/PROTON-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187936#comment-15187936 ] Ken Giusti commented on PROTON-1157: Reviewboard: https://reviews.apache.org/r/44591/ > Reactor sends messages in the clear if ssl is requested by not available. > - > > Key: PROTON-1157 > URL: https://issues.apache.org/jira/browse/PROTON-1157 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.13.0 > > > See > https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 > If 'amqps:' is specified and the SSL libraries are not available the client > will use an unsecured connection instead. This is done silently so the user > is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1157) Reactor sends messages in the clear if ssl is requested by not available.
Ken Giusti created PROTON-1157: -- Summary: Reactor sends messages in the clear if ssl is requested by not available. Key: PROTON-1157 URL: https://issues.apache.org/jira/browse/PROTON-1157 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ken Giusti Priority: Blocker Fix For: 0.13.0 See https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/python/proton/reactor.py#L529 If 'amqps:' is specified and the SSL libraries are not available the client will use an unsecured connection instead. This is done silently so the user is not aware of the security violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1150) Python setup.py fails to use environment settings
[ https://issues.apache.org/jira/browse/PROTON-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1150. Resolution: Fixed > Python setup.py fails to use environment settings > - > > Key: PROTON-1150 > URL: https://issues.apache.org/jira/browse/PROTON-1150 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.13.0 > > > This causes the bindings build/install to ignore any environment variables > that have been set by the user. The setup.py script intends to only modify > the PYTHONPATH env variable when running Popen, but actually results in > resetting all other env variables to their defaults. > See: https://github.com/apache/qpid-proton/pull/69/commits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1150) Python setup.py fails to use environment settings
[ https://issues.apache.org/jira/browse/PROTON-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175679#comment-15175679 ] Ken Giusti commented on PROTON-1150: Ooopsie - I pulled Robert's fix but failed to add the 'PROTON-1150' to the log. Commit is here: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=b9cd200c532e968bc349145b957c586684b08f02 > Python setup.py fails to use environment settings > - > > Key: PROTON-1150 > URL: https://issues.apache.org/jira/browse/PROTON-1150 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.13.0 > > > This causes the bindings build/install to ignore any environment variables > that have been set by the user. The setup.py script intends to only modify > the PYTHONPATH env variable when running Popen, but actually results in > resetting all other env variables to their defaults. > See: https://github.com/apache/qpid-proton/pull/69/commits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1150) Python setup.py fails to use environment settings
Ken Giusti created PROTON-1150: -- Summary: Python setup.py fails to use environment settings Key: PROTON-1150 URL: https://issues.apache.org/jira/browse/PROTON-1150 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.13.0 This causes the bindings build/install to ignore any environment variables that have been set by the user. The setup.py script intends to only modify the PYTHONPATH env variable when running Popen, but actually results in resetting all other env variables to their defaults. See: https://github.com/apache/qpid-proton/pull/69/commits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1133) Proton C includes port number in AMQP Open hostname
[
https://issues.apache.org/jira/browse/PROTON-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159022#comment-15159022
]
Ken Giusti commented on PROTON-1133:
This issue is caused by a defect in the way Reactor obtains the socket address
for its connections.
The reactor - or more specifically, the io_handler used by connections created
via the reactor - expects to find the socket address in the Connection's
'hostname' property. See proton-c/src/reactor/connection.c:pni_handle_bound().
This isn't the correct use of 'hostname' as per the AMQP 1.0 spec:
"The name of the host (either fully qualified or relative) to which the sending
peer is connecting. It is
not mandatory to provide the hostname. If no hostname is provided the receiving
peer SHOULD
select a default based on its own configuration. This field can be used by AMQP
proxies to
determine the correct back-end service to connect the client to.
This field MAY already have been specified by the sasl-init frame, if a SASL
layer is used, or,
the server name indication extension as described in RFC-4366, if a TLS layer
is used, in which
case this field SHOULD be null or contain the same value. It is undefined what
a different value
to that already specified means"
Reactor assumes that the user will set the transport-level address (eg socket
address) in the hostname property. Thus port information needs to be placed in
the 'hostname' (if 5672 is not used). It also forces the user to set hostname
to a numeric address if necessary.
This conflicts with the above specification.
Reactor needs a different approach to configuring the transport-level address
that doesn't conflict with the hostname property.
> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb 8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16)
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b",
> hostname="photoserver:21000", channel-max=32767]
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at
> https://issues.apache.org/jira/browse/DISPATCH-214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1133) Proton C includes port number in AMQP Open hostname
[
https://issues.apache.org/jira/browse/PROTON-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated PROTON-1133:
---
Fix Version/s: 0.13.0
0.12.1
Component/s: python-binding
proton-c
> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb 8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16)
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b",
> hostname="photoserver:21000", channel-max=32767]
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at
> https://issues.apache.org/jira/browse/DISPATCH-214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1133) Proton C includes port number in AMQP Open hostname
[
https://issues.apache.org/jira/browse/PROTON-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated PROTON-1133:
---
Fix Version/s: (was: 0.12.1)
> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb 8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16)
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b",
> hostname="photoserver:21000", channel-max=32767]
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at
> https://issues.apache.org/jira/browse/DISPATCH-214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1123) cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON
[ https://issues.apache.org/jira/browse/PROTON-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1123: --- Fix Version/s: 0.12.0 > cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON > --- > > Key: PROTON-1123 > URL: https://issues.apache.org/jira/browse/PROTON-1123 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: build-failure > Fix For: 0.12.0, 0.13.0 > > > The following syntax error is raised: > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.10") > File "", line 1 > from distutils.sysconfig import get_python_lib; print get_python_lib(True) >^ > SyntaxError: invalid syntax > In python3 print is a function and requires parenthesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1121) Zero pointer derefence in pn_sasl_allowed_mechs()
[ https://issues.apache.org/jira/browse/PROTON-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129031#comment-15129031 ] Ken Giusti commented on PROTON-1121: I've reviewed the patch and it looks fine for 0.12.0 inclusion. > Zero pointer derefence in pn_sasl_allowed_mechs() > - > > Key: PROTON-1121 > URL: https://issues.apache.org/jira/browse/PROTON-1121 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: coverity, crash > Fix For: 0.13.0 > > > Coverity detected a potential derefence of a null string pointer in > pn_sasl_allowed_mechs(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1118: --- Fix Version/s: 0.12.0 > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: build-failure > Fix For: 0.12.0, 0.13.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1123) cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON
Ken Giusti created PROTON-1123: -- Summary: cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON Key: PROTON-1123 URL: https://issues.apache.org/jira/browse/PROTON-1123 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ken Giusti Fix For: 0.12.0 The following syntax error is raised: -- Found Doxygen: /usr/bin/doxygen (found version "1.8.10") File "", line 1 from distutils.sysconfig import get_python_lib; print get_python_lib(True) ^ SyntaxError: invalid syntax In python3 print is a function and requires parenthesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1123) cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON
[ https://issues.apache.org/jira/browse/PROTON-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-1123: -- Assignee: Ken Giusti > cmake fails under python3 when -DSYSINSTALL_BINDINGS=ON > --- > > Key: PROTON-1123 > URL: https://issues.apache.org/jira/browse/PROTON-1123 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.12.0 > > > The following syntax error is raised: > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.10") > File "", line 1 > from distutils.sysconfig import get_python_lib; print get_python_lib(True) >^ > SyntaxError: invalid syntax > In python3 print is a function and requires parenthesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1099) Upload latest stable release of python-qpid-proton onto pypi
[ https://issues.apache.org/jira/browse/PROTON-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1099: --- Priority: Major (was: Blocker) > Upload latest stable release of python-qpid-proton onto pypi > > > Key: PROTON-1099 > URL: https://issues.apache.org/jira/browse/PROTON-1099 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.12.0 > > > A reminder to update Pypi when a new release of proton is available. > I'll move the fix version forward as releases are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1118. Resolution: Fixed > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.13.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1118: --- Fix Version/s: (was: 0.12.0) 0.13.0 > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.13.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1120) Memory leak using proton.utils
[
https://issues.apache.org/jira/browse/PROTON-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127614#comment-15127614
]
Ken Giusti commented on PROTON-1120:
I approve this patch for inclusion into 0.12.0.
> Memory leak using proton.utils
> --
>
> Key: PROTON-1120
> URL: https://issues.apache.org/jira/browse/PROTON-1120
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Environment: python-qpid-proton-0.10-2.fc23.x86_64
> And 0.9-13
>Reporter: Jeff Ortel
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
> Attachments: memory-leak.py
>
>
> I have observed a fairly substantial memory leak using the blocking classes
> in proton.utils. Mainly with sending messages.
> Observations:
> {code}
> growth = 52 MB for 10,000 messages sent
> growth = 104 MB for 20,000 messages sent
> leak = 52 MB per 10,000 sends or ~5 kB / send
> {code}
> The attached reproducer, can be used to collect and display statistics.
> There is likely a better method for measuring the memory growth but this was
> easy. Perhaps there is something incorrect/missing with the way I'm using
> proton or measuring the memory growth/leak?
> {code}
>
> 1 messages
>
> total kB 242088 162567552 - sending
> total kB 293980 68224 59520 - sent
> total kB 293980 68228 59524 - receiving
> total kB 294236 68340 59632 - received
> SizeGrowth Context
> __||__
> 242088 kB +242088 kB sending
> 293980 kB + 51892 kB sent
> 293980 kB + 0 kB receiving
> 294236 kB + 256 kB received
>
> 2 messages
>
> total kB 294236 68348 59640 - sending
> total kB 397820 171896 163232 - sent
> total kB 397820 171900 163236 - receiving
> total kB 398020 172060 163396 - received
> SizeGrowth Context
> __||__
> 294236 kB +294236 kB sending
> 397820 kB +103584 kB sent
> 397820 kB + 0 kB receiving
> 398020 kB + 200 kB received
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1118) python setup.py build fails if run from git repo
Ken Giusti created PROTON-1118: -- Summary: python setup.py build fails if run from git repo Key: PROTON-1118 URL: https://issues.apache.org/jira/browse/PROTON-1118 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.12.0 Reporter: Ken Giusti Fix For: 0.12.0 If setup.py is run from the proton-c/bindings/proton directory, it should build the local python bindings. Instead it tries to download the distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1118) python setup.py build fails if run from git repo
[ https://issues.apache.org/jira/browse/PROTON-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-1118: -- Assignee: Ken Giusti > python setup.py build fails if run from git repo > > > Key: PROTON-1118 > URL: https://issues.apache.org/jira/browse/PROTON-1118 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.12.0 > > > If setup.py is run from the proton-c/bindings/proton directory, it should > build the local python bindings. Instead it tries to download the > distribution from the Apache servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15119755#comment-15119755 ] Ken Giusti commented on PROTON-: Hrm... not sure why this change was made: -from . import _compat +from proton import _compat Why not keep the relative import? Support for pre-2.5 python? > Fix warnings during make doc > > > Key: PROTON- > URL: https://issues.apache.org/jira/browse/PROTON- > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1104. Resolution: Fixed > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10, 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1104: --- Attachment: testcase.c Reproducer. > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114571#comment-15114571 ] Ken Giusti commented on PROTON-1104: Reviewboard: https://reviews.apache.org/r/42700/ > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1104: --- Affects Version/s: 0.10 > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10, 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1086) Release 11.1 and following versions on PyPI
[ https://issues.apache.org/jira/browse/PROTON-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1086. Resolution: Fixed Fix Version/s: 0.11.1 0.11.1 is now available on pypi > Release 11.1 and following versions on PyPI > --- > > Key: PROTON-1086 > URL: https://issues.apache.org/jira/browse/PROTON-1086 > Project: Qpid Proton > Issue Type: Wish > Components: python-binding >Affects Versions: 0.11.0 > Environment: https://pypi.python.org/pypi >Reporter: Javier Ruere >Assignee: Ken Giusti > Fix For: 0.11.1 > > > Versions after 10.0 do not show up in PyPI. > It would be very convenient if the packages were published there like it was > done with version 10. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1099) Upload latest stable release of python-qpid-proton onto pypi
Ken Giusti created PROTON-1099: -- Summary: Upload latest stable release of python-qpid-proton onto pypi Key: PROTON-1099 URL: https://issues.apache.org/jira/browse/PROTON-1099 Project: Qpid Proton Issue Type: Task Components: python-binding Affects Versions: 0.12.0 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.12.0 A reminder to update Pypi when a new release of proton is available. I'll move the fix version forward as releases are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1090. Resolution: Fixed Assignee: Gordon Sim Validated Gordon's change - fix submitted. > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1086) Release 11.1 and following versions on PyPI
[ https://issues.apache.org/jira/browse/PROTON-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-1086: -- Assignee: Ken Giusti > Release 11.1 and following versions on PyPI > --- > > Key: PROTON-1086 > URL: https://issues.apache.org/jira/browse/PROTON-1086 > Project: Qpid Proton > Issue Type: Wish > Components: python-binding >Affects Versions: 0.11.0 > Environment: https://pypi.python.org/pypi >Reporter: Javier Ruere >Assignee: Ken Giusti > > Versions after 10.0 do not show up in PyPI. > It would be very convenient if the packages were published there like it was > done with version 10. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
Ken Giusti created PROTON-1090: -- Summary: BlockingConnection client spins at 100% cpu on reconnect Key: PROTON-1090 URL: https://issues.apache.org/jira/browse/PROTON-1090 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9.1, 0.12.0 Reporter: Ken Giusti Priority: Blocker Fix For: 0.12.0 Attached is a simple python client that connects to a server and waits forever for a message to be received, reconnecting on connection failure. When the server is restarted (in my case I'm using qdrouterd), the client reconnects then pins the cpu at 100%. It appears as if the BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1090: --- Attachment: cputest.py reproducer let it connect to qdrouterd, then restart qdrouterd. cputest.py's cpu will hit 100% once the connection is re-established. Reproduces reliably on fedora22 after a couple of restarts. > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1071) EventInjector hangs on Windows
Ken Giusti created PROTON-1071: -- Summary: EventInjector hangs on Windows Key: PROTON-1071 URL: https://issues.apache.org/jira/browse/PROTON-1071 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.11 Environment: Windows Reporter: Ken Giusti Assignee: Chuck Rolke Fix For: 0.12.0 I added a new reactor test that exercises the python-proton ApplicationEvent and EventInjector classes: proton_tests.reactor.ApplicationEventTest.test_application_events See tests/python/proton_tests/reactor.py This test passes on linux, but hangs when run on Windows. Poking around a bit, I suspect the problem may be in the Windows selector code. Description: The EventInjector/ApplicationEvent classes provide a way to trigger events from threads external to the reactor main loop. See proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the reactor when a new event is sent to the reactor (see reactor.py in the python bindings). The EventInjector's trigger method puts the event on a queue and writes to a pipe to wake up the reactor. The on_selectable_readable callback in the EventInjector is called on the reactor thread to get the event off the queue and clear the pipe. On windows it appears as if the EventInjector selectable is made "readable" even though nothing has been written to the pipe. This causes the os.read() call in the on_selectable_readable() callback to hang. Best I can tell the windows selector code doesn't work properly with a pipe. The pn_selector_next() function is returning a read event on the pipe's read descriptor even though the pipe is empty. But I'm not familiar with the window's selector implementation, so this is a best guess. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1056) Attempting to print an ApplicationEvent raises a NameError
[ https://issues.apache.org/jira/browse/PROTON-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1056. Resolution: Fixed > Attempting to print an ApplicationEvent raises a NameError > -- > > Key: PROTON-1056 > URL: https://issues.apache.org/jira/browse/PROTON-1056 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.12.0 > > > File > "/home/kgiusti/work/rsyslog-omamqp1/external/python/PY27/lib/python2.7/site-packages/proton/reactor.py", > line 278, in __repr__ > return "%s(%s)" % (typename, ", ".join([str(o) for o in objects if o is > not None])) > NameError: global name 'typename' is not defined -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1001) Python tests fail in environments without unittest2
[ https://issues.apache.org/jira/browse/PROTON-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1001. Resolution: Fixed Fix Version/s: 0.11 > Python tests fail in environments without unittest2 > --- > > Key: PROTON-1001 > URL: https://issues.apache.org/jira/browse/PROTON-1001 > Project: Qpid Proton > Issue Type: Bug >Reporter: Justin Ross >Assignee: Ken Giusti > Fix For: 0.11 > > > Provide compatibility with python 2.6: > import unittest > try: > from unittest import SkipTest > except: >try: >from unittest2 import SkipTest >except: >class SkipTest(Exception): >pass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1056) Attempting to print an ApplicationEvent raises a NameError
Ken Giusti created PROTON-1056: -- Summary: Attempting to print an ApplicationEvent raises a NameError Key: PROTON-1056 URL: https://issues.apache.org/jira/browse/PROTON-1056 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.12.0 File "/home/kgiusti/work/rsyslog-omamqp1/external/python/PY27/lib/python2.7/site-packages/proton/reactor.py", line 278, in __repr__ return "%s(%s)" % (typename, ", ".join([str(o) for o in objects if o is not None])) NameError: global name 'typename' is not defined -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1049) Reactor needs an alternative to using the URL to pass user authentication information.
Ken Giusti created PROTON-1049: -- Summary: Reactor needs an alternative to using the URL to pass user authentication information. Key: PROTON-1049 URL: https://issues.apache.org/jira/browse/PROTON-1049 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11 Reporter: Ken Giusti Priority: Blocker Fix For: 0.12.0 When creating a connection using the Container class, the only way to specify the username/password credentials is via the URL. This may cause the credentials to be leaked via the "ps" command if the URL is passed via a command line argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-1003: -- Assignee: Gordon Sim (was: Ken Giusti) Gordon - see previous comment. Appears to be a repeat of the connection handler reference loop, but this time for the link. > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986112#comment-14986112 ] Ken Giusti edited comment on PROTON-1003 at 11/2/15 9:45 PM: - Gordon - see next comment. Appears to be a repeat of the connection handler reference loop, but this time for the link. was (Author: kgiusti): Gordon - see previous comment. Appears to be a repeat of the connection handler reference loop, but this time for the link. > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1032) Cannot call super() on classes derived from Exception in 2.4
Ken Giusti created PROTON-1032: -- Summary: Cannot call super() on classes derived from Exception in 2.4 Key: PROTON-1032 URL: https://issues.apache.org/jira/browse/PROTON-1032 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti The proton 0.9.x series is the last release where python 2.4 is supported (only 2.6+ in 0.10.x+). Code on the 0.9.x branch uses the super() method on Exception derived classes. This is illegal on python 2.4. This fix is only targeted to this branch in case for whatever reason someone stuck with python 2.4 would like to use proton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1032) Cannot call super() on classes derived from Exception in 2.4
[ https://issues.apache.org/jira/browse/PROTON-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980638#comment-14980638 ] Ken Giusti commented on PROTON-1032: https://reviews.apache.org/r/39759/ > Cannot call super() on classes derived from Exception in 2.4 > > > Key: PROTON-1032 > URL: https://issues.apache.org/jira/browse/PROTON-1032 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > > The proton 0.9.x series is the last release where python 2.4 is supported > (only 2.6+ in 0.10.x+). > Code on the 0.9.x branch uses the super() method on Exception derived > classes. This is illegal on python 2.4. > This fix is only targeted to this branch in case for whatever reason someone > stuck with python 2.4 would like to use proton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1033) Update the revision of the libqpid-proton library to 4
Ken Giusti created PROTON-1033: -- Summary: Update the revision of the libqpid-proton library to 4 Key: PROTON-1033 URL: https://issues.apache.org/jira/browse/PROTON-1033 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.11 Reporter: Ken Giusti Assignee: Justin Ross Priority: Blocker Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1031) [python] Bump the module version to 0.11.0
[ https://issues.apache.org/jira/browse/PROTON-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1031. Resolution: Fixed Fix Version/s: 0.12.0 > [python] Bump the module version to 0.11.0 > -- > > Key: PROTON-1031 > URL: https://issues.apache.org/jira/browse/PROTON-1031 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.11, 0.12.0 > > > Update the setup.py script and the module version number before we release > 0.11.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1032) Cannot call super() on classes derived from Exception in 2.4
[ https://issues.apache.org/jira/browse/PROTON-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1032. Resolution: Fixed Fix Version/s: 0.9.1 Not actually fixed in 0.9.1, but there was no "0.9.2" option to select! > Cannot call super() on classes derived from Exception in 2.4 > > > Key: PROTON-1032 > URL: https://issues.apache.org/jira/browse/PROTON-1032 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.9.1 > > > The proton 0.9.x series is the last release where python 2.4 is supported > (only 2.6+ in 0.10.x+). > Code on the 0.9.x branch uses the super() method on Exception derived > classes. This is illegal on python 2.4. > This fix is only targeted to this branch in case for whatever reason someone > stuck with python 2.4 would like to use proton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1003: --- Fix Version/s: 0.11 > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Ken Giusti > Fix For: 0.11 > > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1029) Do not fail hard if strerror_r fails.
[ https://issues.apache.org/jira/browse/PROTON-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1029. Resolution: Fixed > Do not fail hard if strerror_r fails. > - > > Key: PROTON-1029 > URL: https://issues.apache.org/jira/browse/PROTON-1029 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.11 > > > The return type from strerror_r differs depending on the compiler's feature > set. > if _GNU_SOURCE is defined, strerror_r returns a char * > if _POSIX_C_SOURCE is defined to a certain set of values, strerror_r returns > an int. > proton expects int, and fails hard (aborts) when a string ptr is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[
https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978548#comment-14978548
]
Ken Giusti commented on PROTON-905:
---
I think that we should bump this off until post 0.11 and bump the priority down
to major.
This bug doesn't affect any application that uses proton's event-based
processing model. This model is the preferred usage (as opposed to the 'walk
all {links,deliveries,sessions} looking for work to do).
AFAIK - all the proton client code now uses the event-based approach.
I've tested this against qpidd-0.34 (event-based implementation) and there is
no memory buildup.
Lastly, this is not a regression as it's been present at least as far back as
the 0.9 series.
> Long-lived connections leak sessions and links
> --
>
> Key: PROTON-905
> URL: https://issues.apache.org/jira/browse/PROTON-905
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.9.1, 0.10
>Reporter: Ken Giusti
>Assignee: Rafael H. Schloming
>Priority: Critical
> Fix For: 0.11
>
> Attachments: test-send.py
>
>
> I found this issue while debugging a crash dump of qpidd.
> Long lived connections do not free its sessions/link.
> This only applies when NOT using the event model. The version of qpidd I
> tested against (0.30) still uses the iterative model. Point to consider, I
> don't know why this is the case.
> Details: I have a test script that opens a single connection, then
> continually creates sessions/links over that connection, sending one message
> before closing and freeing the sessions/links. See attached.
> Over time the qpidd run time consumes all memory on the system and is killed
> by OOM. To be clear, I'm using drain to remove all sent messages - there is
> no message build up.
> On debugging this, I'm finding thousands of session objects on the
> connections free sessions weakref list. Every one of those sessions has a
> refcount of one.
> Once the connection is finalized, all session objects are freed. But until
> then, freed sessions continue to accumulate indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1029) Do not fail hard if strerror_r fails.
Ken Giusti created PROTON-1029: -- Summary: Do not fail hard if strerror_r fails. Key: PROTON-1029 URL: https://issues.apache.org/jira/browse/PROTON-1029 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.11 The return type from strerror_r differs depending on the compiler's feature set. if _GNU_SOURCE is defined, strerror_r returns a char * if _POSIX_C_SOURCE is defined to a certain set of values, strerror_r returns an int. proton expects int, and fails hard (aborts) when a string ptr is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1010) BlockingConnection leaks sockets after close() is called
Ken Giusti created PROTON-1010: -- Summary: BlockingConnection leaks sockets after close() is called Key: PROTON-1010 URL: https://issues.apache.org/jira/browse/PROTON-1010 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Fix For: 0.11 Using the attached reproducer and connecting to a qpid-dispatch router, there are many connections that are left half-closed indefinitely. The reproducer fails to close it's socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed PROTON-1000.
--
Resolution: Fixed
Reactor is not properly cleaning up the underlying socket.
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1010) BlockingConnection leaks sockets after close() is called
[ https://issues.apache.org/jira/browse/PROTON-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-1010: --- Attachment: pavel.py Pavel's reproducer. Remove the comment on 'self.conn.run()' and the sockets are properly closed and released. > BlockingConnection leaks sockets after close() is called > > > Key: PROTON-1010 > URL: https://issues.apache.org/jira/browse/PROTON-1010 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti > Fix For: 0.11 > > Attachments: pavel.py > > > Using the attached reproducer and connecting to a qpid-dispatch router, there > are many connections that are left half-closed indefinitely. The reproducer > fails to close it's socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (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 ] Ken Giusti reassigned PROTON-1006: -- Assignee: Gordon Sim > 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] [Resolved] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1003. Resolution: Fixed Pushed Gordon's fix. > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Ken Giusti > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1001) Python tests fail in environments without unittest2
[ https://issues.apache.org/jira/browse/PROTON-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-1001: -- Assignee: Ken Giusti > Python tests fail in environments without unittest2 > --- > > Key: PROTON-1001 > URL: https://issues.apache.org/jira/browse/PROTON-1001 > Project: Qpid Proton > Issue Type: Bug >Reporter: Justin Ross >Assignee: Ken Giusti > > Provide compatibility with python 2.6: > import unittest > try: > from unittest import SkipTest > except: >try: >from unittest2 import SkipTest >except: >class SkipTest(Exception): >pass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-987) Do not assume clock_gettime is available - use system default if not.
[ https://issues.apache.org/jira/browse/PROTON-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-987. --- Resolution: Fixed > Do not assume clock_gettime is available - use system default if not. > - > > Key: PROTON-987 > URL: https://issues.apache.org/jira/browse/PROTON-987 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 >Reporter: Ken Giusti > Fix For: 0.10.1 > > > The python setup.py script assumes the system call clock_gettime is available > and always sets the USE_CLOCK_GETTIME compilation flag. Instead, it should > check for clock_gettime() and only set the flag if it is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-987) Do not assume clock_gettime is available - use system default if not.
Ken Giusti created PROTON-987: - Summary: Do not assume clock_gettime is available - use system default if not. Key: PROTON-987 URL: https://issues.apache.org/jira/browse/PROTON-987 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.10 Reporter: Ken Giusti Fix For: 0.10.1 The python setup.py script assumes the system call clock_gettime is available and always sets the USE_CLOCK_GETTIME compilation flag. Instead, it should check for clock_gettime() and only set the flag if it is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-985) Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock time
Ken Giusti created PROTON-985: - Summary: Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock time Key: PROTON-985 URL: https://issues.apache.org/jira/browse/PROTON-985 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.11 The timestamp argument to pn_transport_tick is a pn_timestamp_t. pn_timestamp_t implies real time (wall clock) in that it's expressed as a time value based on epoch. As seen in QPID-6698, using a real time value for that argument can lead to problems if the real time is adjusted (eg. timezone, daylight savings, drift). Instead, pn_transport_tick should be passed a monotonic clock source - one that does not reflect changes in real time. All documentation and examples should be updated accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-109) Proton should handle inbound max-frame size violations.
[ https://issues.apache.org/jira/browse/PROTON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-109. --- Resolution: Fixed Fix Version/s: 0.10 Proton should handle inbound max-frame size violations. --- Key: PROTON-109 URL: https://issues.apache.org/jira/browse/PROTON-109 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 According to the spec, if the local proton-c client has configured a maximum frame size, and the remote attempts to send a frame that violates that size: A peer that receives an oversized frame MUST close the Connection with the framing-error error-code. Need to verify this behavior is handled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-976) pn_read_frame does not validate frame offset
[ https://issues.apache.org/jira/browse/PROTON-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-976. --- Resolution: Fixed pn_read_frame does not validate frame offset Key: PROTON-976 URL: https://issues.apache.org/jira/browse/PROTON-976 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 pn_read_frame in framing.c does not validate the doff with respect to the frame size. If doff is corrupt proton will still attempt to parse the frame. This can result in a crash. I consider this a blocker as an attacker can craft a bad frame that results in crashing the receiver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-975) crash occurs if buffer containing outcome and first encrypted frame is received
[ https://issues.apache.org/jira/browse/PROTON-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659925#comment-14659925 ] Ken Giusti commented on PROTON-975: --- Ah, thanks robbie I missed that. crash occurs if buffer containing outcome and first encrypted frame is received --- Key: PROTON-975 URL: https://issues.apache.org/jira/browse/PROTON-975 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 Attachments: send.py I'm hitting an occasional client crash when using an DIGEST-MD5 SASL mech to talk to the qpidd broker. I've built the broker using the 0.10rc1 as the proton library. I'm using a pyngus based client. I will upload this reproducer. Best I can tell, the client pushes a single buffer to the transport that contains both the SASL outcome frame from qpidd and the first encrypted frame. SASL does not handle this case correctly and attempts to parse the encrypted frame as cleartext. I will open another bug against the frame decode to prevent parsing invalid frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-975) crash occurs if buffer containing outcome and first encrypted frame is received
Ken Giusti created PROTON-975: - Summary: crash occurs if buffer containing outcome and first encrypted frame is received Key: PROTON-975 URL: https://issues.apache.org/jira/browse/PROTON-975 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Priority: Blocker Fix For: 0.10 I'm hitting an occasional client crash when using an DIGEST-MD5 SASL mech to talk to the qpidd broker. I've built the broker using the 0.10rc1 as the proton library. I'm using a pyngus based client. I will upload this reproducer. Best I can tell, the client pushes a single buffer to the transport that contains both the SASL outcome frame from qpidd and the first encrypted frame. SASL does not handle this case correctly and attempts to parse the encrypted frame as cleartext. I will open another bug against the frame decode to prevent parsing invalid frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-953) Travis CI tox tests fail to correctly build python 2.6 extension lib
[
https://issues.apache.org/jira/browse/PROTON-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-953.
---
Resolution: Fixed
Travis CI tox tests fail to correctly build python 2.6 extension lib
Key: PROTON-953
URL: https://issues.apache.org/jira/browse/PROTON-953
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.10
Environment: Travis CI ubuntu
Reporter: Andrew Stitcher
Assignee: Ken Giusti
In the current Travis CI build the tox tests fail to correctly build the
python 2.6 extension lib:
{noformat}
...
test 3
Start 3: python-tox-test
3: Test command: /home/travis/virtualenv/python2.7.9/bin/python
/home/travis/build/apache/qpid-proton/proton-c/env.py
PATH=/home/travis/build/apache/qpid-proton/Build/proton-c:/home/travis/build/apache/qpid-proton/Build/tests/tools/apps/c:/home/travis/build/apache/qpid-proton/tests/tools/apps/python:/home/travis/.local/bin:/home/travis/virtualenv/python2.7.9/bin:/home/travis/bin:/home/travis/.local/bin:/home/travis/.gimme/versions/go1.4.1.linux.amd64/bin:/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.2/bin:/opt/python/3.3.5/bin:/opt/python/3.2.5/bin:/opt/python/pypy-2.5.0/bin:/opt/python/pypy3-2.4.0/bin:/usr/local/phantomjs/bin:/home/travis/.nvm/v0.10.36/bin:./node_modules/.bin:/usr/local/maven-3.2.5/bin:/usr/local/clang-3.4/bin:/home/travis/.gimme/versions/go1.4.1.linux.amd64/bin:/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.2/bin:/opt/python/3.3.5/bin:/opt/python/3.2.5/bin:/opt/python/pypy-2.5.0/bin:/opt/python/pypy3-2.4.0/bin:/usr/local/phantomjs/bin:./node_modules/.bin:/usr/local/maven-3.2.5/bin:/usr/local/clang-3.4/bin:/home/travis/.gimme/versions/go1.4.1.linux.amd64/bin:/home/travis/.rvm/gems/ruby-1.9.3-p551/bin:/home/travis/.rvm/gems/ruby-1.9.3-p551@global/bin:/home/travis/.rvm/rubies/ruby-1.9.3-p551/bin:/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.2/bin:/opt/python/3.3.5/bin:/opt/python/3.2.5/bin:/opt/python/pypy-2.5.0/bin:/opt/python/pypy3-2.4.0/bin:/usr/local/phantomjs/bin:./node_modules/.bin:/usr/local/maven-3.2.5/bin:/usr/local/clang-3.4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/travis/.rvm/bin:/home/travis/.rvm/bin:/home/travis/.rvm/bin
QPID_PROTON_SRC=/home/travis/build/apache/qpid-proton/proton-c/../
CLASSPATH=/home/travis/build/apache/qpid-proton/Build/proton-j/proton-j.jar
SASLPASSWD=/usr/sbin/saslpasswd2 SWIG=/usr/bin/swig2.0
VALGRIND=/usr/bin/valgrind /home/travis/virtualenv/python2.7.9/bin/tox
3: Test timeout computed to be: 1500
3: GLOB sdist-make:
/home/travis/build/apache/qpid-proton/proton-c/bindings/python/setup.py
3: py26 create:
/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/py26
3: py26 inst:
/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/dist/python-qpid-proton-0.10.0.zip
3: ERROR: invocation failed (exit code 1), logfile:
/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/py26/log/py26-1.log
3: ERROR: actionid: py26
3: msg: installpkg
3: cmdargs:
[local('/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/py26/bin/pip'),
'install',
'/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/dist/python-qpid-proton-0.10.0.zip']
3: env: {'rvm_version': '1.26.8 (1.26.8)', 'LC_CTYPE': 'en_US.UTF-8',
'TRAVIS': 'true', 'TRAVIS_REPO_SLUG': 'apache/qpid-proton', 'JRUBY_OPTS':
'--client -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1
-Xcext.enabled=false -J-Xss2m -Xcompile.invokedynamic=false', 'VIRTUAL_ENV':
'/home/travis/build/apache/qpid-proton/proton-c/bindings/python/.tox/py26',
'SHELL': '/bin/bash', 'TRAVIS_BRANCH': 'master', 'rvm_with_default_gems':
'rake=~10.2.2 bundler=~1.6.0', 'VALGRIND': '/usr/bin/valgrind', 'NVM_BIN':
'/home/travis/.nvm/v0.10.36/bin', 'VIRTUAL_ENV_DISABLE_PROMPT': 'true',
'MANPATH':
'/home/travis/.nvm/v0.10.36/share/man:/usr/local/clang-3.4/share/man:/usr/local/man:/usr/local/share/man:/usr/share/man',
'JAVA_HOME': '/usr/lib/jvm/java-7-oracle', '_system_type': 'Linux',
'TRAVIS_SECURE_ENV_VARS': 'false', 'MY_RUBY_HOME':
'/home/travis/.rvm/rubies/ruby-1.9.3-p551', 'rvm_max_time_flag': '5',
'RUBY_VERSION': 'ruby-1.9.3-p551', '_system_version': '12.04',
'TRAVIS_COMMIT_RANGE': 'd9ce3cfd0916...8f82638b7e82', 'MAIL':
'/var/mail/travis', 'rvm_bin_path': '/home/travis/.rvm/bin',
'CONTINUOUS_INTEGRATION': 'true', 'GOROOT':
'/home/travis/.gimme/versions/go1.4.1.linux.amd64', 'rvm_path':
'/home/travis/.rvm', 'RACK_ENV': 'test', 'USER': 'travis',
'NVM_IOJS_ORG_MIRROR': 'https://iojs.org/dist', 'PS4': '+', 'SHLVL': '3',
'MERB_ENV': 'test', 'GIT_ASKPASS': 'echo', 'GEM_PATH':
[jira] [Resolved] (PROTON-951) Make install fails when building Proton-C with python 3.4
[
https://issues.apache.org/jira/browse/PROTON-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-951.
---
Resolution: Fixed
Make install fails when building Proton-C with python 3.4
-
Key: PROTON-951
URL: https://issues.apache.org/jira/browse/PROTON-951
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.10
Reporter: Andrew Stitcher
Assignee: Ken Giusti
Attachments: py34fail
When building proton-C using a python 3.4 virtualenv make install fails:
{noformat}
$ source ~/LocalPython/Python3/bin/activate
$ cmake -DCMAKE_INSTALL_PREFIX=$PWD/install ../src
$ cmake --build . --target install
{noformat}
{noformat}
...
CMake Error at proton-c/bindings/python/cmake_install.cmake:106 (file):
file INSTALL cannot find
/home/andrew/Work/proton/bld-python3/proton-c/bindings/python/cproton.pyc.
Call Stack (most recent call first):
proton-c/bindings/cmake_install.cmake:37 (include)
proton-c/cmake_install.cmake:139 (include)
cmake_install.cmake:50 (include)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-961) messenger doesn't handle multi-frame transfers
[ https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645998#comment-14645998 ] Ken Giusti commented on PROTON-961: --- Thanks for the analysis - I agree that Gordon's fix is a good start and should be comitted. Haven't thought this through entirely, but for 0.10 would it make sense to add a temp workaround in messenger that automagically bumps the session-incoming_capacity from 1M to some huge number if the max-frame is configured? Would that avoid the session stall for 'reasonable' message sizes? messenger doesn't handle multi-frame transfers -- Key: PROTON-961 URL: https://issues.apache.org/jira/browse/PROTON-961 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1, 0.10, 0.11 Reporter: Gordon Sim See QPID-6651 for a reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-923.
---
Resolution: Fixed
Re-tested with 0.10 Beta1 and concur - the TRANSPORT_ERROR event is now
properly posted.
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-961) messenger doesn't handle multi-frame transfers
[ https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642853#comment-14642853 ] Ken Giusti commented on PROTON-961: --- From my understanding of the code, I'd think your change is the correct fix. There are tests for receiving fragmented messages and large messages in the engine unit tests, but not for messenger. messenger doesn't handle multi-frame transfers -- Key: PROTON-961 URL: https://issues.apache.org/jira/browse/PROTON-961 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10, 0.11 Reporter: Gordon Sim See QPID-6651 for a reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-961) messenger doesn't handle multi-frame transfers
[ https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643071#comment-14643071 ] Ken Giusti commented on PROTON-961: --- Let me retract that - this isn't the correct fix. I tried hacking a copy of messenger to set the max-frame on its connections to 128 bytes. A few of the unit tests start failing with that setting, so I applied Gordon's fix above. His fix prevents a few of the failures, but proton_tests.messenger.MessengerTest.testSendReceive1M fails. Turns out even with that patch Messenger will hang for messages = 1meg. This is caused by the incoming-window closing on the receiver. Since the transfers are partial, messenger never calls pn_link_advance or pn_link_recv, which replenishes the incoming window. messenger doesn't handle multi-frame transfers -- Key: PROTON-961 URL: https://issues.apache.org/jira/browse/PROTON-961 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10, 0.11 Reporter: Gordon Sim See QPID-6651 for a reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-958) [python] pip installed binding fails to find correct libqpid-proton.so
[ https://issues.apache.org/jira/browse/PROTON-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-958. --- Resolution: Fixed [python] pip installed binding fails to find correct libqpid-proton.so -- Key: PROTON-958 URL: https://issues.apache.org/jira/browse/PROTON-958 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 The latest versions of pip keeps a cache of downloaded packages. It also caches the results of any extensions built for those packages. When a user tries to re-install (or install in a different virtualenv) a previously build package, the pre-built package is pulled from the cache and plopped into place. Which is all great and fast... ... unless your extension also builds a shared library (libqpid-proton) and sets its RPATH to it. This ends up with a cached _cproton.so with a RPATH pointing to the directory where the libqpid-proton.so was installed. Woe be you if that was a virtualenv that you deleted (or updated). This results in either libqpid-proton.so not found errors when importing the bindings, or symbol mismatches if the library was overwritten. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-952) Building Proton with python 2.6 and python 3.4 on Travis CI finds and links wrong libpython
[ https://issues.apache.org/jira/browse/PROTON-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-952. - Resolution: Won't Fix Have confirmed this is a cmake bug when run under virtualenv. Upgraded cmake to 3.3.0 and the correct libraries are found. Building Proton with python 2.6 and python 3.4 on Travis CI finds and links wrong libpython --- Key: PROTON-952 URL: https://issues.apache.org/jira/browse/PROTON-952 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Environment: Travis CI build environment (highly customised Ubuntu) Reporter: Andrew Stitcher Assignee: Ken Giusti You can specify a specifiv version of python to use in the Traviis build process and that will set up the build environment to use a python virtualenv with that version of python. When using python 2.6 or 3.4 (and probably 3.3 too but I've not tested that) the cmake installed will find the python 2.7 libs and link them into the proton bindings extension. This seems to succeed at build time but seems to make the python-test fail to even start in both cases (though with slightly different symptoms). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-952) Building Proton with python 2.6 and python 3.4 on Travis CI finds and links wrong libpython
[ https://issues.apache.org/jira/browse/PROTON-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643205#comment-14643205 ] Ken Giusti commented on PROTON-952: --- I'm fairly certain this is a cmake bug that is triggered when running an older cmake under a virtualenv. It reproduces on ubuntu 14 LTS (cmake 2.8.12) but not on my fedora 21 box with a newer (3.0.2) cmake. There have been reports of such issues (python interpreter/library mismatches), not necessarily virtualenv related: http://www.itk.org/Bug/view.php?id=13794 Building Proton with python 2.6 and python 3.4 on Travis CI finds and links wrong libpython --- Key: PROTON-952 URL: https://issues.apache.org/jira/browse/PROTON-952 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Environment: Travis CI build environment (highly customised Ubuntu) Reporter: Andrew Stitcher Assignee: Ken Giusti You can specify a specifiv version of python to use in the Traviis build process and that will set up the build environment to use a python virtualenv with that version of python. When using python 2.6 or 3.4 (and probably 3.3 too but I've not tested that) the cmake installed will find the python 2.7 libs and link them into the proton bindings extension. This seems to succeed at build time but seems to make the python-test fail to even start in both cases (though with slightly different symptoms). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-958) [python] pip installed binding fails to find correct libqpid-proton.so
[ https://issues.apache.org/jira/browse/PROTON-958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14639440#comment-14639440 ] Ken Giusti commented on PROTON-958: --- Reviewboard link: https://reviews.apache.org/r/36744/ [python] pip installed binding fails to find correct libqpid-proton.so -- Key: PROTON-958 URL: https://issues.apache.org/jira/browse/PROTON-958 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 The latest versions of pip keeps a cache of downloaded packages. It also caches the results of any extensions built for those packages. When a user tries to re-install (or install in a different virtualenv) a previously build package, the pre-built package is pulled from the cache and plopped into place. Which is all great and fast... ... unless your extension also builds a shared library (libqpid-proton) and sets its RPATH to it. This ends up with a cached _cproton.so with a RPATH pointing to the directory where the libqpid-proton.so was installed. Woe be you if that was a virtualenv that you deleted (or updated). This results in either libqpid-proton.so not found errors when importing the bindings, or symbol mismatches if the library was overwritten. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-943) Bump library (.so) major version for proton-c libraries
[ https://issues.apache.org/jira/browse/PROTON-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-943: - Assignee: Ken Giusti Bump library (.so) major version for proton-c libraries --- Key: PROTON-943 URL: https://issues.apache.org/jira/browse/PROTON-943 Project: Qpid Proton Issue Type: Task Components: proton-c Reporter: Ted Ross Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 0.10 contains incompatible API changes. The library major versions need to be incremented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-476) Support a user-context for SASL and SSL objects.
[ https://issues.apache.org/jira/browse/PROTON-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-476. - Resolution: Won't Fix Fix Version/s: (was: 0.9) Probably no longer necessary - the new attachments interface allows multiple contexts to be associated with the transport (which is the parent of both the SASL and SSL objects). Support a user-context for SASL and SSL objects. Key: PROTON-476 URL: https://issues.apache.org/jira/browse/PROTON-476 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Assignee: Ken Giusti For consistency and convenience, I'd like to add an API that would allow an application-defined context be associated with the pn_sasl_t, pn_ssl_domain_t, and pn_ssl_t objects. This api would follow the convention used by other proton classes (eg, pn_connection_get_context(), pn_connection_set_context()). ex: void *pn_sasl_get_context(pn_sasl_t); void pn_sasl_set_context(pn_sasl_t *, void *context); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-941) pn_transport_set_server should fail if invoked after binding.
Ken Giusti created PROTON-941: - Summary: pn_transport_set_server should fail if invoked after binding. Key: PROTON-941 URL: https://issues.apache.org/jira/browse/PROTON-941 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 Transport server configuration needs to be completed before the transport is bound (and before either the transport's SSL or SASL components are created). pn_transport_set_server should fail if called too late in the configuration process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-941) pn_transport_set_server should fail if invoked after binding.
[ https://issues.apache.org/jira/browse/PROTON-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622519#comment-14622519 ] Ken Giusti commented on PROTON-941: --- Yeah, hit this in qpid-dispatch (C code). Never had this issue in pyngus (python) since the API more 'idiot proof'. /me is a bigger idiot in C, I guess ;) pn_transport_set_server should fail if invoked after binding. -- Key: PROTON-941 URL: https://issues.apache.org/jira/browse/PROTON-941 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 Transport server configuration needs to be completed before the transport is bound (and before either the transport's SSL or SASL components are created). pn_transport_set_server should fail if called too late in the configuration process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-939) [SSL] Regression: binding a transport erases the configured peer name
Ken Giusti created PROTON-939: - Summary: [SSL] Regression: binding a transport erases the configured peer name Key: PROTON-939 URL: https://issues.apache.org/jira/browse/PROTON-939 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 If the SSL instance is configured _before_ binding, and no hostname has been configured for the connection to be bound, the peer hostname as configured on the SSL object is reset (no hostname set). To be compatible with the previous releases of proton, pn_ssl_set_peer_hostname() should take precedence over the hostname configured for the connection. e.g. the connection's hostname should be used by default, unless a hostname has been explicitly set via pn_ssl_set_peer_hostname(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-939) [SSL] Regression: binding a transport erases the configured peer name
[ https://issues.apache.org/jira/browse/PROTON-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-939. --- Resolution: Fixed [SSL] Regression: binding a transport erases the configured peer name - Key: PROTON-939 URL: https://issues.apache.org/jira/browse/PROTON-939 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 If the SSL instance is configured _before_ binding, and no hostname has been configured for the connection to be bound, the peer hostname as configured on the SSL object is reset (no hostname set). To be compatible with the previous releases of proton, pn_ssl_set_peer_hostname() should take precedence over the hostname configured for the connection. e.g. the connection's hostname should be used by default, unless a hostname has been explicitly set via pn_ssl_set_peer_hostname(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-929) [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete
Ken Giusti created PROTON-929: - Summary: [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete Key: PROTON-929 URL: https://issues.apache.org/jira/browse/PROTON-929 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 If both sides of the connection specify just the ANONYMOUS mech, then the connection open does not complete. The frame trace for the connection attempt: ./test-runner unit_tests.connection.APITest.test_sasl_callbacks unit_tests.connection.APITest.test_sasl_callbacks ...[0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x228c1e0]: - AMQP [0x228c1e0]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x2475800]:Authenticated user: anonymous with mechanism ANONYMOUS [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x2475800]:0 - @sasl-outcome(68) [code=0] [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-1, channel-max=32767] [0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x228c1e0]:0 - @sasl-outcome(68) [code=0] hangs waiting for connection to open The server's open frame is never processed by the client, though it has been received 'on the wire'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
Ken Giusti created PROTON-923:
-
Summary: [SASL] PN_TRANSPORT_ERROR event not raised
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do not
share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on the
client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from the
SASL failure itself, but rather from a framing error occuring on the server
(which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-922) [python] setup.py fails to build bindings if qpid-proton-c-devel installed
[ https://issues.apache.org/jira/browse/PROTON-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-922. --- Resolution: Fixed [python] setup.py fails to build bindings if qpid-proton-c-devel installed -- Key: PROTON-922 URL: https://issues.apache.org/jira/browse/PROTON-922 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 When pip attempts to install the python-qpid-proton sdist, and the proton devel package has been installed, the installation fails. setup.py finds that the necessary proton headers and library have been installed, so setup.py attempts to swig the installed headers. swig fails to find the headers and the install fails. The failure is due to the setup.py not passing the correct -I search path to swig. It should pass the search path found by pkg-config -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-922) [python] setup.py fails to build bindings if qpid-proton-c-devel installed
Ken Giusti created PROTON-922: - Summary: [python] setup.py fails to build bindings if qpid-proton-c-devel installed Key: PROTON-922 URL: https://issues.apache.org/jira/browse/PROTON-922 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 When pip attempts to install the python-qpid-proton sdist, and the proton devel package has been installed, the installation fails. setup.py finds that the necessary proton headers and library have been installed, so setup.py attempts to swig the installed headers. swig fails to find the headers and the install fails. The failure is due to the setup.py not passing the correct -I search path to swig. It should pass the search path found by pkg-config -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-905. --- Resolution: Fixed Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-885) Allow setup.py to bundle qpid-proton
[ https://issues.apache.org/jira/browse/PROTON-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-885. --- Resolution: Fixed Allow setup.py to bundle qpid-proton Key: PROTON-885 URL: https://issues.apache.org/jira/browse/PROTON-885 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.9.1 Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Allow-setup.py-for-bundling-proton.patch Allow setup.py for bundling proton As of now, it's not possible to install python-qpid-proton if libqpid-proton is not present in the system. To be more precises, it's possible to build python-qpid-proton using cmake, upload it and beg to the gods of OPs that the required (and correct) shared library will be present in the system. This patch adds to python-qpid-proton the ability to download, build and install qpid-proton if the required version is not present in the system. It does this by checking - using pkg-config - whether the required version is installed and if not, it goes to downloading the package from the official apache source and builds it using cmake. As nasty as it sounds, this process is not strange in the Python community. Very famous - and way more used - libraries like PyZMQ (from which this work took lots of inspiration) do this already in a fairly more complex way. This first step is quite simple, it checks, downloads and builds using the standard tools. It's enabled just for linux and it does not use fancy flags. Future enhancements could take care of improving the implementation and extending it to support other systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-885) Allow setup.py to bundle qpid-proton
[ https://issues.apache.org/jira/browse/PROTON-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-885: -- Affects Version/s: 0.9.1 Fix Version/s: 0.10 Allow setup.py to bundle qpid-proton Key: PROTON-885 URL: https://issues.apache.org/jira/browse/PROTON-885 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.9.1 Reporter: Flavio Percoco Assignee: Ken Giusti Fix For: 0.10 Attachments: 0001-Allow-setup.py-for-bundling-proton.patch Allow setup.py for bundling proton As of now, it's not possible to install python-qpid-proton if libqpid-proton is not present in the system. To be more precises, it's possible to build python-qpid-proton using cmake, upload it and beg to the gods of OPs that the required (and correct) shared library will be present in the system. This patch adds to python-qpid-proton the ability to download, build and install qpid-proton if the required version is not present in the system. It does this by checking - using pkg-config - whether the required version is installed and if not, it goes to downloading the package from the official apache source and builds it using cmake. As nasty as it sounds, this process is not strange in the Python community. Very famous - and way more used - libraries like PyZMQ (from which this work took lots of inspiration) do this already in a fairly more complex way. This first step is quite simple, it checks, downloads and builds using the standard tools. It's enabled just for linux and it does not use fancy flags. Future enhancements could take care of improving the implementation and extending it to support other systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-908) Use swig as a build dependency when possible
[ https://issues.apache.org/jira/browse/PROTON-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-908. --- Resolution: Fixed Fix Version/s: 0.10 Use swig as a build dependency when possible Key: PROTON-908 URL: https://issues.apache.org/jira/browse/PROTON-908 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Fix For: 0.10 Attachments: 0001-PROTON-908-Remove-install-runtime-dependency-on-swig.patch python-qpid-proton depends on swig to generate the C/python wrappers for proton-c. It is possible to soften this dependency by making it a build (sdist in python jargon) dependency instead of a runtime/install dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-756) add a new/simpler setup.py for python bindings
[ https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-756: - Assignee: Ken Giusti (was: Darryl L. Pierce) add a new/simpler setup.py for python bindings -- Key: PROTON-756 URL: https://issues.apache.org/jira/browse/PROTON-756 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Rafael H. Schloming Assignee: Ken Giusti Priority: Blocker Fix For: 0.9 Attachments: 0001-PROTON-756-Add-the-proton-directory-to-the-install-p.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-895. --- Resolution: Fixed Fix Version/s: 0.10 Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Fix For: 0.10 Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-756) add a new/simpler setup.py for python bindings
[ https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-756. - Resolution: Duplicate Fix Version/s: (was: 0.9) 0.10 add a new/simpler setup.py for python bindings -- Key: PROTON-756 URL: https://issues.apache.org/jira/browse/PROTON-756 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Rafael H. Schloming Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 Attachments: 0001-PROTON-756-Add-the-proton-directory-to-the-install-p.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-917) [SASL] buffer underrun if no mechs specified by peer
[ https://issues.apache.org/jira/browse/PROTON-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-917. --- Resolution: Fixed [SASL] buffer underrun if no mechs specified by peer Key: PROTON-917 URL: https://issues.apache.org/jira/browse/PROTON-917 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 off by one array index error if the peer doesn't supply any mechs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-842) proton-c should honor channel_max
[ https://issues.apache.org/jira/browse/PROTON-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-842: -- Component/s: (was: proton-c) proton-j Affects Version/s: 0.10 proton-c should honor channel_max - Key: PROTON-842 URL: https://issues.apache.org/jira/browse/PROTON-842 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9, 0.10 Reporter: michael goulish Assignee: michael goulish proton-c code should use transport-channel_max and transport-remote_channel_max to enforce a limit on the maximum number of simultaneously active sessions on a connection. I guess the limit should be the minimum of those two numbers, or, if neither side sets a limit, then 2^16. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-916) [SASL] pn_sasl_config_name - name gets overwritten in python binding
[ https://issues.apache.org/jira/browse/PROTON-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-916. --- Resolution: Fixed [SASL] pn_sasl_config_name - name gets overwritten in python binding Key: PROTON-916 URL: https://issues.apache.org/jira/browse/PROTON-916 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 When setting the SASL configuration name from python, a pointer to a temporary string is passed to pn_sasl_config_name() by the python environment. When the environment no longer references that string, the memory is freed, leaving the sasl internal object referencing freed memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-917) [SASL] buffer underrun if no mechs specified by peer
Ken Giusti created PROTON-917: - Summary: [SASL] buffer underrun if no mechs specified by peer Key: PROTON-917 URL: https://issues.apache.org/jira/browse/PROTON-917 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 off by one array index error if the peer doesn't supply any mechs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-916) [SASL] pn_sasl_config_name - name gets overwritten in python binding
Ken Giusti created PROTON-916: - Summary: [SASL] pn_sasl_config_name - name gets overwritten in python binding Key: PROTON-916 URL: https://issues.apache.org/jira/browse/PROTON-916 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 When setting the SASL configuration name from python, a pointer to a temporary string is passed to pn_sasl_config_name() by the python environment. When the environment no longer references that string, the memory is freed, leaving the sasl internal object referencing freed memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-908) Use swig as a build dependency when possible
[ https://issues.apache.org/jira/browse/PROTON-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-908: - Assignee: Ken Giusti Use swig as a build dependency when possible Key: PROTON-908 URL: https://issues.apache.org/jira/browse/PROTON-908 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-PROTON-908-Remove-install-runtime-dependency-on-swig.patch python-qpid-proton depends on swig to generate the C/python wrappers for proton-c. It is possible to soften this dependency by making it a build (sdist in python jargon) dependency instead of a runtime/install dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-904) Remove dependency on libuuid
[ https://issues.apache.org/jira/browse/PROTON-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-904. - Resolution: Fixed Fix Version/s: 0.10 Remove dependency on libuuid Key: PROTON-904 URL: https://issues.apache.org/jira/browse/PROTON-904 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Fix For: 0.10 The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to remove this dependency by adding a built-in uuid4 generator since uuid4 is based on random bytes generation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-904) Remove dependency on libuuid
[ https://issues.apache.org/jira/browse/PROTON-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-904: - Assignee: Ken Giusti Remove dependency on libuuid Key: PROTON-904 URL: https://issues.apache.org/jira/browse/PROTON-904 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Fix For: 0.10 The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to remove this dependency by adding a built-in uuid4 generator since uuid4 is based on random bytes generation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581918#comment-14581918 ] Ken Giusti commented on PROTON-905: --- reviewboard link: https://reviews.apache.org/r/35355/ Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-905: -- Attachment: test-send.py A test pyngus script that can reproduce the problem when run against the 0.30 qpidd broker. Remember to run 'drain -f amq.topic' in the background to prevent message build up. Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Priority: Blocker Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
