[jira] [Created] (PROTON-2810) C++ compile standard needs to be advanced to c++14 or later
Kim van der Riet created PROTON-2810: Summary: C++ compile standard needs to be advanced to c++14 or later Key: PROTON-2810 URL: https://issues.apache.org/jira/browse/PROTON-2810 Project: Qpid Proton Issue Type: Bug Components: cpp-binding, examples Reporter: Kim van der Riet The use of opentelemetry-cpp API in qpid-proton is forcing the C++ compile standard to be c++14 or later. The support for c++11 (which qpid-proton is currently using) in opentelemetry-cpp was removed in v 1.12.0 (we are currently at version 1.14.2), and the use of its APIs is causing compile errors. Consideration should be given to moving the compiler C++ standard to 14, 17 or even 20. I have tested the compile using c++17, and this does not create any compile errors, and solves the opentelemetry-cpp API error too. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2652) Travis CI failure for Focal/Clang: Investigate file descriptor loss test failure
Kim van der Riet created PROTON-2652:
Summary: Travis CI failure for Focal/Clang: Investigate file
descriptor loss test failure
Key: PROTON-2652
URL: https://issues.apache.org/jira/browse/PROTON-2652
Project: Qpid Proton
Issue Type: Bug
Reporter: Kim van der Riet
The Travis CI build:
[https://app.travis-ci.com/github/apache/qpid-proton/builds/257509704]
failed python-integration-test with "AssertionError: Found \{'9'} new fd(s)
after the test"
[https://app.travis-ci.com/github/apache/qpid-proton/jobs/587757462]
This failure should be investigated - is it a test bug or a product bug?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542634#comment-17542634
]
Kim van der Riet edited comment on PROTON-2550 at 5/26/22 7:05 PM:
---
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to {{sys.path}} as
follows:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{sys.exec_prefix}}; empty
heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} (on Unix
and macOS). For each of the distinct head-tail combinations, it sees if it
refers to an existing directory, and if so, adds it to {{sys.path}} and also
inspects the newly added path for configuration files.
...
A path configuration file is a file whose name has the form {{name.pth}} and
exists in one of the four directories mentioned above; its contents are
additional items (one per line) to be added to {{sys.path}}. Non-existing items
are never added to {{sys.path}}, and no check is made that the item refers to a
directory rather than a file. No item is added to {{sys.path}} more than once.
Blank lines and lines beginning with # are skipped. Lines starting with import
(followed by space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/3/library/site.html]
was (Author: kpvdr):
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to {{sys.path}} as
follows:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is insuffi
[jira] [Comment Edited] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542634#comment-17542634
]
Kim van der Riet edited comment on PROTON-2550 at 5/26/22 6:38 PM:
---
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to {{sys.path}} as
follows:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
was (Author: kpvdr):
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to sys.path as follows:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is in
[jira] [Comment Edited] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542634#comment-17542634
]
Kim van der Riet edited comment on PROTON-2550 at 5/26/22 6:37 PM:
---
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to sys.path as follows:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
was (Author: kpvdr):
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to sys.path:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is insufficient to u
[jira] [Commented] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542634#comment-17542634
]
Kim van der Riet commented on PROTON-2550:
--
The success of the system install may lie in the easy-install.pth file that is
created in the site-packages directory. According to the Python
documentation[1], the contents of this file are added to sys.path:
{quote}It starts by constructing up to four directories from a head and a tail
part. For the head part, it uses {{sys.prefix}} and {{{}sys.exec_prefix{}}};
empty heads are skipped. For the tail part, it uses the empty string and then
{{lib/site-packages}} (on Windows) or {{lib/pythonX.Y/site-packages}} and then
{{lib/site-python}} (on Unix and Macintosh). For each of the distinct head-tail
combinations, it sees if it refers to an existing directory, and if so, adds it
to sys.path and also inspects the newly added path for configuration files.
A path configuration file is a file whose name has the form name.pth and exists
in one of the four directories mentioned above; its contents are additional
items (one per line) to be added to sys.path. Non-existing items are never
added to sys.path, and no check is made that the item refers to a directory
rather than a file. No item is added to sys.path more than once. Blank lines
and lines beginning with # are skipped. Lines starting with import (followed by
space or tab) are executed.
{quote}
I notice that the path tail combinations for Unix do not include {{{}lib64{}}},
only {{{}lib{}}}. I wonder if this is contributing to the failure to find the
{{.pth}} file for local installs. For that matter, it would not work for system
installs either.
[1] [https://docs.python.org/2/library/site.html]
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is insufficient to use module proton, even with the PYTHONPATH set:
> {noformat}
> $ cd ~ # Exit from dist directory which contains python install artifacts
> $ echo $PYTHONPATH
> /tmp/lib64/python3.10/site-packages
> $ python
> >>> import proton
> Traceback (most recent call last):
> File "", line 1, in
> ModuleNotFoundError: No module named 'proton'
> >>>
> {noformat}
> However, a workaround exists by adding a symbolic link *{{proton}}* pointing
> to the .egg directory:
> {noformat}
> $ cd /tmp/lib64/python3.10/site-packages/
> $ ln -s python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg proton
> $ cd ~ # Exit from dist directory which contains python install artifacts
> $ python
> >>> import proton
> >>> proton.__path__
> _NamespacePath(['/tmp/lib64/python3.10/site-packages/proton'])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542585#comment-17542585
]
Kim van der Riet edited comment on PROTON-2550 at 5/26/22 5:12 PM:
---
I did a check on what happens if a system install is used without the
*{{--prefix}}* option. In this case, the identical directory structure is
created in {*}{{/usr/local/lib64}}{*}. And with no *{{PYTHONPATH}}* set, python
finds the proton module ok:
{noformat}
$ unset PYTHONPATH
$ cd python/dist/
$ python setup.py install # Tried non-root install first
...
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied: '/usr/local/lib64/python3.10'
...
$ sudo python setup.py install
...
$ ll /usr/local/lib64/python3.10/site-packages/
total 8
-rw-r--r--. 1 root root 57 May 26 12:36 easy-install.pth
drwxr-xr-x. 5 root root 4096 May 26 12:36
python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
$ cd ~ # Exit from dist directory which contains python install artifacts
$ python
>>> import proton
>>> proton.__path__
['/usr/local/lib64/python3.10/site-packages/python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg/proton']
>>>
{noformat}
So it seems that a local install does not work with a PYTHONPATH set, but with
system install which uses the same directory structure in a system location,
python finds the proton directory within the .egg directory. What are we
missing? How do we make local installs work?
was (Author: kpvdr):
I did a check on what happens if the install is used without the *{{--prefix}}*
option. In this case, the identical directory structure is created in
{*}{{/usr/local/lib64}}{*}. And with no *{{PYTHONPATH}}* set, python finds the
proton module ok:
{noformat}
$ unset PYTHONPATH
$ cd python/dist/
$ python setup.py install # Tried non-root install first
...
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied: '/usr/local/lib64/python3.10'
...
$ sudo python setup.py install
...
$ ll /usr/local/lib64/python3.10/site-packages/
total 8
-rw-r--r--. 1 root root 57 May 26 12:36 easy-install.pth
drwxr-xr-x. 5 root root 4096 May 26 12:36
python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
$ cd ~ # Exit from dist directory which contains python install artifacts
$ python
>>> import proton
>>> proton.__path__
['/usr/local/lib64/python3.10/site-packages/python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg/proton']
>>>
{noformat}
So it seems that a local install does not work with a PYTHONPATH set, but with
system install which uses the same directory structure in a system location,
python finds the proton directory within the .egg directory. What are we
missing? How do we make local installs work?
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is insufficient to use module proton, even with the PYTHONPATH set:
> {noformat}
> $ cd ~ # Exit from dist directory which contains python install artifacts
> $ echo $PYTHONPATH
> /tmp/lib64/python3.10/site-packages
> $ python
> >>> import proton
> Traceback (most recent call last):
> File "", line 1, in
> ModuleNotFoundError: No module named 'proton'
> >>>
> {noformat}
> However, a workaround exists by adding a symbolic link *{{proton}}* pointing
> to the .egg directory
[jira] [Commented] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
[
https://issues.apache.org/jira/browse/PROTON-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542585#comment-17542585
]
Kim van der Riet commented on PROTON-2550:
--
I did a check on what happens if the install is used without the *{{--prefix}}*
option. In this case, the identical directory structure is created in
{*}{{/usr/local/lib64}}{*}. And with no *{{PYTHONPATH}}* set, python finds the
proton module ok:
{noformat}
$ unset PYTHONPATH
$ cd python/dist/
$ python setup.py install # Tried non-root install first
...
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied: '/usr/local/lib64/python3.10'
...
$ sudo python setup.py install
...
$ ll /usr/local/lib64/python3.10/site-packages/
total 8
-rw-r--r--. 1 root root 57 May 26 12:36 easy-install.pth
drwxr-xr-x. 5 root root 4096 May 26 12:36
python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
$ cd ~ # Exit from dist directory which contains python install artifacts
$ python
>>> import proton
>>> proton.__path__
['/usr/local/lib64/python3.10/site-packages/python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg/proton']
>>>
{noformat}
So it seems that a local install does not work with a PYTHONPATH set, but with
system install which uses the same directory structure in a system location,
python finds the proton directory within the .egg directory. What are we
missing? How do we make local installs work?
> [python-binding] setup.py install does not create module directory when using
> --prefix
> --
>
> Key: PROTON-2550
> URL: https://issues.apache.org/jira/browse/PROTON-2550
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>
> After building proton, installing the python bindings using the generated
> *{{setup.py}}* does not create all of the necessary directories when used
> with the *{{--prefix}}* option. In particular, a directory using the module
> name *{{proton}}* is missing.
> The following install command from the cmake build directory:
> {noformat}
> $ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
> $ cd python/dist/
> $ python setup.py install --prefix /tmp
> $ ls -l /tmp/lib64/python3.10/site-packages/
> total 3
> -rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
> drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
> python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
> {noformat}
> produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
> directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
> to the install).
> This is insufficient to use module proton, even with the PYTHONPATH set:
> {noformat}
> $ cd ~ # Exit from dist directory which contains python install artifacts
> $ echo $PYTHONPATH
> /tmp/lib64/python3.10/site-packages
> $ python
> >>> import proton
> Traceback (most recent call last):
> File "", line 1, in
> ModuleNotFoundError: No module named 'proton'
> >>>
> {noformat}
> However, a workaround exists by adding a symbolic link *{{proton}}* pointing
> to the .egg directory:
> {noformat}
> $ cd /tmp/lib64/python3.10/site-packages/
> $ ln -s python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg proton
> $ cd ~ # Exit from dist directory which contains python install artifacts
> $ python
> >>> import proton
> >>> proton.__path__
> _NamespacePath(['/tmp/lib64/python3.10/site-packages/proton'])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2550) [python-binding] setup.py install does not create module directory when using --prefix
Kim van der Riet created PROTON-2550:
Summary: [python-binding] setup.py install does not create module
directory when using --prefix
Key: PROTON-2550
URL: https://issues.apache.org/jira/browse/PROTON-2550
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Reporter: Kim van der Riet
Assignee: Andrew Stitcher
After building proton, installing the python bindings using the generated
*{{setup.py}}* does not create all of the necessary directories when used with
the *{{--prefix}}* option. In particular, a directory using the module name
*{{proton}}* is missing.
The following install command from the cmake build directory:
{noformat}
$ export PYTHONPATH=/tmp/lib64/python3.10/site-packages
$ cd python/dist/
$ python setup.py install --prefix /tmp
$ ls -l /tmp/lib64/python3.10/site-packages/
total 3
-rw-rw-r--. 1 kvdr kvdr 57 May 26 11:58 easy-install.pth
drwxrwxr-x. 5 kvdr kvdr 160 May 26 11:58
python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg
{noformat}
produces a single {{python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg}}
directory (and a {{easy-install.pth}} file if the {{PYTHONPATH}} is set prior
to the install).
This is insufficient to use module proton, even with the PYTHONPATH set:
{noformat}
$ cd ~ # Exit from dist directory which contains python install artifacts
$ echo $PYTHONPATH
/tmp/lib64/python3.10/site-packages
$ python
>>> import proton
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'proton'
>>>
{noformat}
However, a workaround exists by adding a symbolic link *{{proton}}* pointing to
the .egg directory:
{noformat}
$ cd /tmp/lib64/python3.10/site-packages/
$ ln -s python_qpid_proton-0.38.0.dev0-py3.10-linux-x86_64.egg proton
$ cd ~ # Exit from dist directory which contains python install artifacts
$ python
>>> import proton
>>> proton.__path__
_NamespacePath(['/tmp/lib64/python3.10/site-packages/proton'])
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-108) [C++ shim] Update use of Json::Reader and Json::FastWriter which are deprecated
[
https://issues.apache.org/jira/browse/QPIDIT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPIDIT-108.
-
Resolution: Fixed
This was fixed some time ago.
> [C++ shim] Update use of Json::Reader and Json::FastWriter which are
> deprecated
> ---
>
> Key: QPIDIT-108
> URL: https://issues.apache.org/jira/browse/QPIDIT-108
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Task
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
>
> Recent versions of Fedora are warning that use of {{Json::Reader}} and
> {{Json::FastWriter}} are now deprecated. Check that whatever replaces this
> will at a minimum run on RHEL7 / CentOS7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-126) Add build-time or run-time check for availability of the Python{2|3}-qpid-proton packages
[
https://issues.apache.org/jira/browse/QPIDIT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-126.
---
Resolution: Won't Fix
Proton 2 is no longer supported. This issue is now moot.
> Add build-time or run-time check for availability of the
> Python{2|3}-qpid-proton packages
> -
>
> Key: QPIDIT-126
> URL: https://issues.apache.org/jira/browse/QPIDIT-126
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Task
> Components: Proton Python Shim
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
>
> The qpid-interop-tests run both Python 2 and Python 3 shims by default. No
> check is performed on the availability of the API on the host machine. The
> shims may be disabled manually, however, by the use of the {{--exclude-shim}}
> command-line option.
> Not all supported operating systems have packages for both Python 2 and
> Python 3 APIs. It will be necessary to perform either a build-time or
> run-time check for the availability of these packages and enable/disable the
> shims accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-46) Correctly encode AMQP types within complex types list and map
[
https://issues.apache.org/jira/browse/QPIDIT-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-46.
--
> Correctly encode AMQP types within complex types list and map
> -
>
> Key: QPIDIT-46
> URL: https://issues.apache.org/jira/browse/QPIDIT-46
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: AMQP Types Test, Proton C++ Shim, Proton Python Shim,
> Rhea JavaScript Shim
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> Currently the AMQP type tests for list and map are using only strings. An
> extra step for encoding/decoding these on the Sender/Receiver shims are
> needed. At present, the list and map keys and elements are created using a
> string format {{"type:value"}}, but these are simply being used as-is as
> string literals.
> Currently all shim tests for these types pass.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-130) 'utils' module is versioned incorrectly
[ https://issues.apache.org/jira/browse/QPIDIT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-130. --- > 'utils' module is versioned incorrectly > --- > > Key: QPIDIT-130 > URL: https://issues.apache.org/jira/browse/QPIDIT-130 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Installation >Affects Versions: 0.2.0 >Reporter: Robbie Gemmell > Assignee: Kim van der Riet >Priority: Blocker > Fix For: 0.2.0 > > > The utils module is incorrectly still versioned as 0.1.0. This has obviously > already been released and so must be corrected to 0.2.0 to prevent conflict. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-128) misuse of JAVA_HOME causes tests to error without clear indication why
[
https://issues.apache.org/jira/browse/QPIDIT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-128.
---
> misuse of JAVA_HOME causes tests to error without clear indication why
> --
>
> Key: QPIDIT-128
> URL: https://issues.apache.org/jira/browse/QPIDIT-128
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Qpid Jms Shim
>Affects Versions: 0.1.0, 0.2.0
>Reporter: Robbie Gemmell
> Assignee: Kim van der Riet
>Priority: Critical
> Fix For: 0.2.0
>
>
> The interop suite misuses JAVA_HOME, and in doing so Python tries to run java
> from the wrong place. This results in the tests erroring out with note of a
> file not found, but with no indication what file wasn't found. Resorting to
> some prints for debugging, it emerges that Python is being asked to run Java
> with the wrong location
> JAVA_HOME points to the root of the java installation, with the java command
> and various others then found in the bin subdir. The interop tests currently
> omit the bin subdir when JAVA_HOME was actually defined, but do include it
> (via a fragile and debatable hard coded default) when JAVA_HOME is not
> defined:
> {noformat}
> JAVA_HOME = os.getenv('JAVA_HOME', '/usr/bin') # Default only works in Linux
> JAVA_EXEC = os.path.join(JAVA_HOME, 'java')
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-129) tests reference wrong 'shim' version for Qpid JMS
[
https://issues.apache.org/jira/browse/QPIDIT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-129.
---
> tests reference wrong 'shim' version for Qpid JMS
> -
>
> Key: QPIDIT-129
> URL: https://issues.apache.org/jira/browse/QPIDIT-129
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.2.0
>Reporter: Robbie Gemmell
> Assignee: Kim van der Riet
>Priority: Blocker
> Fix For: 0.2.0
>
>
> The installed 0.2.0 RC2 tests look for the wrong shim, at:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.1.0-jar-with-dependencies.jar
> {noformat}
> While the file actually installed, after the changes in RC2 is now correctly
> named:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.2.0-jar-with-dependencies.jar
> {noformat}
> This causes the tests to fail (once QPIDIT-128 is worked around).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-79) Stopping Python tests using ctrl+c sometimes results in a zombie shim
[ https://issues.apache.org/jira/browse/QPIDIT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-79. -- > Stopping Python tests using ctrl+c sometimes results in a zombie shim > - > > Key: QPIDIT-79 > URL: https://issues.apache.org/jira/browse/QPIDIT-79 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Labels: gotcha > Fix For: 0.2.0 > > > When interrupting some tests (particularly Python tests) using ctrl+c will > stop the test, but will sometimes leave a zombie process behind (either a > Sender or a Receiver process). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-109) Add ability to run Proton Python shims under Python 3
[ https://issues.apache.org/jira/browse/QPIDIT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-109. --- > Add ability to run Proton Python shims under Python 3 > - > > Key: QPIDIT-109 > URL: https://issues.apache.org/jira/browse/QPIDIT-109 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > Currently the shims run under Python 2.7, so add Python 3 as additional shim > type. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-107) Add support for JMS message properties in ProtonCpp shim
[ https://issues.apache.org/jira/browse/QPIDIT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-107. --- > Add support for JMS message properties in ProtonCpp shim > > > Key: QPIDIT-107 > URL: https://issues.apache.org/jira/browse/QPIDIT-107 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton C++ Shim >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > Currently the properties section of the test is disabled because the C++ > bindings did not support access to message properties at the time the shim > was first written. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-106) Cmake does not find custom-installed maven
[
https://issues.apache.org/jira/browse/QPIDIT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-106.
---
> Cmake does not find custom-installed maven
> --
>
> Key: QPIDIT-106
> URL: https://issues.apache.org/jira/browse/QPIDIT-106
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.1.0
> Environment: RHEL7, CentOS7
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> When building qpid-interop-test on a platform where Maven is custom-installed
> directly from the Apache web site (owing to the packaged version being too
> early a version to work), the installed {{mvn}} command is not found by the
> installer and installation is aborted.
> This occurs where maven is installed into a custom location such as
> {{/usr/local/maven}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-115) Print both stderr and stdout output when stderr output is detected on a shim
[ https://issues.apache.org/jira/browse/QPIDIT-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-115. --- > Print both stderr and stdout output when stderr output is detected on a shim > > > Key: QPIDIT-115 > URL: https://issues.apache.org/jira/browse/QPIDIT-115 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > The AMQP.NetLite shims sometimes produce spurious error messages on stderr > that can be ignored (see QPIDIT-113). Fixing this highlighted the fact that > when stderr output exists, any output on stdout is ignored. If a shim should > produce messages on stderr, it would be useful to also see any stdout output > (if it exists). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-110) Add check for failure of Sender shim, if so, kill Receiver shim
[ https://issues.apache.org/jira/browse/QPIDIT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-110. --- > Add check for failure of Sender shim, if so, kill Receiver shim > --- > > Key: QPIDIT-110 > URL: https://issues.apache.org/jira/browse/QPIDIT-110 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > Currently the sender and receiver shims check for failures independently of > each other. However, if the Sender shim fails, the receiver shim should be > killed, as there is no point waiting for it. Currently, this allows the > receiver to wait until the full duration of the test timeout before being > killed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-113) AMQP.NetLite shims produce error message on stderr which should be ignored
[
https://issues.apache.org/jira/browse/QPIDIT-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-113.
---
> AMQP.NetLite shims produce error message on stderr which should be ignored
> --
>
> Key: QPIDIT-113
> URL: https://issues.apache.org/jira/browse/QPIDIT-113
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> While running the AMQP .NetLite shims on CentOS7, the shims produce a single
> instance of the following error message on stderr:
> {noformat}
> Got a bad hardware address length for an AF_PACKET 20 8{noformat}
> As the tests treat _any_ text on stderr as an error condition, the tests
> fail. In fact the shims are behaving normally in every other way and complete
> the tests normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-125) Release QIT 0.2.0
[ https://issues.apache.org/jira/browse/QPIDIT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-125. --- > Release QIT 0.2.0 > - > > Key: QPIDIT-125 > URL: https://issues.apache.org/jira/browse/QPIDIT-125 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > Update docs, create branches, tags, etc. for the release of Qpid Interop Test > v. 0.2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-119) Add AMQP complex type test
[ https://issues.apache.org/jira/browse/QPIDIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-119. --- > Add AMQP complex type test > -- > > Key: QPIDIT-119 > URL: https://issues.apache.org/jira/browse/QPIDIT-119 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Complex Types Test >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.2.0 > > > The AMQP types test cover the simple tests well, but do not do a good job of > the complex types. This is because the ability to represent the test data for > the complex types is itself a complex issue, as each complex type may contain > an arbitrary number of other complex types. For example, a list may contain > other lists or maps, and maps may contain other lists and maps as both keys > and values. > Solving this problem requires that a mechanism exist to create and represent > an arbitrarily large and complex set of data for testing, and allow the sent > and received data to be compared to determine success or failure. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-136) Python 2.7 site packages path appearing in Python 3 PYTHONPATH
[
https://issues.apache.org/jira/browse/QPIDIT-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-136.
---
> Python 2.7 site packages path appearing in Python 3 PYTHONPATH
> --
>
> Key: QPIDIT-136
> URL: https://issues.apache.org/jira/browse/QPIDIT-136
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> The environment variable {{PYTHON3PATH}} is set up as a holder for
> {{PYTHONPATH}} when running the shims under Python 3. After installing, the
> value of PYTHON3PATH contains a path segment containing
> {{lib/python2.7/site-packages}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-61) Condense common code from the Python tests into a test module.
[ https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-61. -- > Condense common code from the Python tests into a test module. > -- > > Key: QPIDIT-61 > URL: https://issues.apache.org/jira/browse/QPIDIT-61 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Large Content Test, AMQP Types Test, JMS Headers > and Properties Test, JMS Message Test >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.2.0 > > > Each test was written independently of the others. While this is a quick way > to start, it has not lead to a lot of duplicated code and common patterns. It > would help maintenance and readability of the code if the common bits were > placed into a test library. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-37) Add test timeout to receiver shims so that when not all expected messages are received, the test does not wait indefinitely
[ https://issues.apache.org/jira/browse/QPIDIT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-37. -- > Add test timeout to receiver shims so that when not all expected messages are > received, the test does not wait indefinitely > --- > > Key: QPIDIT-37 > URL: https://issues.apache.org/jira/browse/QPIDIT-37 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Large Content Test, AMQP Types Test, JMS Headers > and Properties Test, JMS Message Test >Affects Versions: 0.1.0 > Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.2.0 > > > Sometimes the broker fails or does not deliver the expected number of > messages. Currently the shims wait indefinitely for the messages, and this > causes the test to effectively hang instead of failing and allowing the > following test to run. > Add a timeout to the tests so that the test will fail gracefully if not all > messages are received within a reasonable time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-65) Add command-line controls to JMS_hdrs_props_test to control test more precisely
[
https://issues.apache.org/jira/browse/QPIDIT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-65.
--
> Add command-line controls to JMS_hdrs_props_test to control test more
> precisely
> ---
>
> Key: QPIDIT-65
> URL: https://issues.apache.org/jira/browse/QPIDIT-65
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Improvement
> Components: JMS Headers and Properties Test
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
>
> The JMS hdrs_props_test needs additional command-line parameters to control
> the test precisely. Since the test by default uses only the JMS_MESSAGE_TYPE
> for this test, the --{include, exclude}-type paramter has no effect at
> present, but should be used to change/modify the base message type. In
> addition, a parameter switching on/off the headers and parameters is needed,
> also a control for the type of header and type of parameters used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-85) Tests don't limit the number of times it tries to connect to a broker
[
https://issues.apache.org/jira/browse/QPIDIT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-85.
--
> Tests don't limit the number of times it tries to connect to a broker
> -
>
> Key: QPIDIT-85
> URL: https://issues.apache.org/jira/browse/QPIDIT-85
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
>
> When no broker is present, or when a misconfiguration prevents communication
> to the broker, then the test keeps attempting to connect without time or
> number limit:
> {noformat}
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ...
> {noformat}
> and will keep trying indefinitely, effectively hanging the test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-93) Optionally produce xUnit XML report with test results
[
https://issues.apache.org/jira/browse/QPIDIT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet closed QPIDIT-93.
--
> Optionally produce xUnit XML report with test results
> -
>
> Key: QPIDIT-93
> URL: https://issues.apache.org/jira/browse/QPIDIT-93
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Improvement
>Affects Versions: 0.1.0
>Reporter: Jiri Daněk
> Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
> Attachments: amqp_types_test.2018-01-26T09-24-24.xml,
> jms_hdrs_props_test.2018-01-26T09-45-29.xml, xunit.xsd
>
>
> Something like the following should do the job. Instead of
> https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to
> maybe switch from unittest package to py.test, which has xUnit reports built
> in.
> {noformat}
> diff --git a/src/python/qpid_interop_test/jms_messages_test.py
> b/src/python/qpid_interop_test/jms_messages_test.py
> index 3b54510..3b94f3a 100755
> --- a/src/python/qpid_interop_test/jms_messages_test.py
> +++ b/src/python/qpid_interop_test/jms_messages_test.py
> @@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
> from json import dumps
> from os import getenv, path
> +import xmlrunner
> from proton import symbol
> from qpid_interop_test.test_type_map import TestTypeMap
> @@ -302,7 +300,7 @@ class TestOptions(object):
> Class controlling command-line arguments used to control the test.
> """
> def __init__(self, shim_map):
> -parser = argparse.ArgumentParser(description='Qpid-interop AMQP
> client interoparability test suite '
> +parser = argparse.ArgumentParser(description='Qpid-interop AMQP
> client interoperability test suite '
> 'for JMS message types')
> parser.add_argument('--sender', action='store',
> default='localhost:5672', metavar='IP-ADDR:PORT',
> help='Node to which test suite will send
> messages.')
> @@ -313,6 +311,8 @@ class TestOptions(object):
> parser.add_argument('--broker-type', action='store',
> metavar='BROKER_NAME',
> help='Disable test of broker type (using
> connection properties) by specifying the broker' +
> ' name, or "None".')
> +parser.add_argument('--xunit-report-dir', action='store',
> metavar='REPORTS_DIRECTORY',
> +help='Generate xUnit report into
> REPORTS_DIRECTORY/TEST--.xml')
> type_group = parser.add_mutually_exclusive_group()
> type_group.add_argument('--include-type', action='append',
> metavar='JMS_MESSAGE-TYPE',
> help='Name of JMS message type to include.
> Supported types:\n%s' %
> @@ -421,6 +421,7 @@ if __name__ == '__main__':
> TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
>
> # Finally, run all the dynamically created tests
> -RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
> +#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE) # type:
> unittest.TextTestResult
> +RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE) # type:
> unittest.TextTestResult
> if not RES.wasSuccessful():
> sys.exit(1)
> {noformat}
> The main "problem" seems that each test has completely separate main method
> and builds up options from scratch. Adding this to every test would mean some
> unnecessary duplication. So maybe refactor this somewhat at first? On the
> other hand, there are good reasons to keep the tests simple...
> What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-112) Change test queue prefix from "jms.queue.qpid_interop" to "qit"
[ https://issues.apache.org/jira/browse/QPIDIT-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-112. --- > Change test queue prefix from "jms.queue.qpid_interop" to "qit" > --- > > Key: QPIDIT-112 > URL: https://issues.apache.org/jira/browse/QPIDIT-112 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.2.0 > > > When this test suite was first tested against the Activemq Artemis broker, it > could not auto-create queues other than those prefixed with "jms.queue". As > this test suite relies on the ability of the broker to auto-create queues, > this became the wired-in prefix for all test queue names. > Artemis now no longer has this limitation. Change the test queue prefix to > something shorter like "qit". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-127) update to use the current v19 apache parent pom
[ https://issues.apache.org/jira/browse/QPIDIT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-127. --- > update to use the current v19 apache parent pom > --- > > Key: QPIDIT-127 > URL: https://issues.apache.org/jira/browse/QPIDIT-127 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Installation, Qpid Jms Shim >Affects Versions: 0.2.0 >Reporter: Robbie Gemmell > Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.2.0 > > > update to use the current v19 apache parent pom to better align with other > components going forward (e.g see also QPIDJMS-397) and aid in consistent use > of plugin versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-143) Remove Python 2 shims
[ https://issues.apache.org/jira/browse/QPIDIT-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-143. - Resolution: Fixed > Remove Python 2 shims > - > > Key: QPIDIT-143 > URL: https://issues.apache.org/jira/browse/QPIDIT-143 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.3.0 > > > The Python 2 shims are obsolete. By removing them, there is some code > simplification that can take place to remove _compat and bilingual bits from > the shims. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-143) Remove Python 2 shims
Kim van der Riet created QPIDIT-143: --- Summary: Remove Python 2 shims Key: QPIDIT-143 URL: https://issues.apache.org/jira/browse/QPIDIT-143 Project: Apache QPID Interoperability Test Suite Issue Type: Task Reporter: Kim van der Riet Assignee: Kim van der Riet Fix For: 0.3.0 The Python 2 shims are obsolete. By removing them, there is some code simplification that can take place to remove _compat and bilingual bits from the shims. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-141) Incorrect handling of binary types
[ https://issues.apache.org/jira/browse/QPIDIT-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-141. - Resolution: Fixed > Incorrect handling of binary types > -- > > Key: QPIDIT-141 > URL: https://issues.apache.org/jira/browse/QPIDIT-141 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, JMS Headers and Properties Test, JMS > Message Test >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.3.0 > > > When binary test values are sent using JSON to the shims, they are converted > to strings, as JSON cannot handle binary values. With the conversion of QIT > tests to Python 3, the encoding of binary to strings has become an issue > (under Py2, binary and str were synonymous). > It is probably best that the binary be encoded into base64 and then converted > to a string for use as a value in JSON. Each shim would then have to decode > these values back to an appropriate binary value. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-141) Incorrect handling of binary types
[ https://issues.apache.org/jira/browse/QPIDIT-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-141: Fix Version/s: 0.3.0 > Incorrect handling of binary types > -- > > Key: QPIDIT-141 > URL: https://issues.apache.org/jira/browse/QPIDIT-141 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, JMS Headers and Properties Test, JMS > Message Test >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.3.0 > > > When binary test values are sent using JSON to the shims, they are converted > to strings, as JSON cannot handle binary values. With the conversion of QIT > tests to Python 3, the encoding of binary to strings has become an issue > (under Py2, binary and str were synonymous). > It is probably best that the binary be encoded into base64 and then converted > to a string for use as a value in JSON. Each shim would then have to decode > these values back to an appropriate binary value. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-142) Remove complex types from amqp_types_test, rename to amqp_simple_types_test
[ https://issues.apache.org/jira/browse/QPIDIT-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-142. - Resolution: Fixed > Remove complex types from amqp_types_test, rename to amqp_simple_types_test > --- > > Key: QPIDIT-142 > URL: https://issues.apache.org/jira/browse/QPIDIT-142 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Types Test > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.3.0 > > > amqp_types_test contains a few arbitrary maps and lists. However, these > complex AMQP types (which can be arbitrarily deeply encoded) are now covered > in the amqp_complex_types_test. In addition, the shims for these complex > types were not recursively encoding the subtypes contained in these types, > but were using the string representation of the subtypes. This makes them of > limited usefulness. > I suggest that these tests be removed. > In addition, I suggest that amqp_types_test be renamed to > amqp_simple_types_test to help clearly distinguish it from the complex type > test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-142) Remove complex types from amqp_types_test, rename to amqp_simple_types_test
[ https://issues.apache.org/jira/browse/QPIDIT-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-142: Fix Version/s: 0.3.0 > Remove complex types from amqp_types_test, rename to amqp_simple_types_test > --- > > Key: QPIDIT-142 > URL: https://issues.apache.org/jira/browse/QPIDIT-142 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Types Test > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > Fix For: 0.3.0 > > > amqp_types_test contains a few arbitrary maps and lists. However, these > complex AMQP types (which can be arbitrarily deeply encoded) are now covered > in the amqp_complex_types_test. In addition, the shims for these complex > types were not recursively encoding the subtypes contained in these types, > but were using the string representation of the subtypes. This makes them of > limited usefulness. > I suggest that these tests be removed. > In addition, I suggest that amqp_types_test be renamed to > amqp_simple_types_test to help clearly distinguish it from the complex type > test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2341) Cannot build Dispatch using the Debian PPA Proton packages
[
https://issues.apache.org/jira/browse/PROTON-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342695#comment-17342695
]
Kim van der Riet commented on PROTON-2341:
--
I rebuilt:
* qpid-proton (0.34.0-1focal+qpid1) focal
* qpid-proton (0.34.0-1bionic+qpid1) bionic
I switched the {{libqpid-proton-proactor1-dev}} dependency from
{{libqpid-proton11-dev}} to {{libqpid-proton-core10-dev}} in the control file.
This provides the missing lib, and also provides a dep to the replaced
{{libqpid-proton11-dev}}. So hopefully this will resolve this issue.
> Cannot build Dispatch using the Debian PPA Proton packages
> --
>
> Key: PROTON-2341
> URL: https://issues.apache.org/jira/browse/PROTON-2341
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, release
>Affects Versions: proton-c-0.33.0
> Environment: Ubuntu Focal
>Reporter: Jiri Daněk
>Assignee: Irina Boverman
>Priority: Major
>
> I am installing Proton from PPA
> {noformat}
> $ sudo add-apt-repository ppa:qpid/testing && sudo apt-get update
> $ sudo apt install -y libqpid-proton-proactor1-dev python3-qpid-proton
> {noformat}
> I run Dispatch compilation, but I get error
> {noformat}
> -- Found Proton:
> optimized;/usr/lib/x86_64-linux-gnu/libqpid-proton.so;debug;/usr/lib/x86_64-linux-gnu/libqpid-proton.so
> (found version "0.33.0")
> {noformat}
> (notice that the .so mentioned in this cmake output does not actually exist
> in the package, there it is named with extra .10 at the end.)
> {noformat}
> [...]
> [ 81%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> [ 83%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http2/http2_adaptor.c.o
> make[3]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/libqpid-proton-core.so', needed by
> 'src/libqpid-dispatch.so'. Stop.
> make[2]: *** [CMakeFiles/Makefile2:1072:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:1296: docs/CMakeFiles/docs.dir/rule] Error
> 2
> make: *** [Makefile:662: docs] Error 2
> Error: Process completed with exit code 2.
> {noformat}
> To workaround this, I have to do
> {noformat}
> sudo ln -s /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so.10
> /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so
> {noformat}
> and then the build succeeds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2341) Cannot build Dispatch using the Debian PPA Proton packages
[
https://issues.apache.org/jira/browse/PROTON-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340911#comment-17340911
]
Kim van der Riet edited comment on PROTON-2341 at 5/7/21, 4:01 PM:
---
According to the debian/control file:
{{Package: libqpid-proton-proactor1-dev}}
Provides: libqpid-proton-proactor-dev
{{Depends: libqpid-proton11-dev (>= ${binary:Version}),
libqpid-proton-proactor1 (= ${binary:Version}), $\{misc:Depends}}}
{{...}}
and is missing a dep on {{libqpid-proton-core10-dev}} which provides the
missing file.
was (Author: kpvdr):
According to the debian/control file:
{{Package: libqpid-proton-proactor1-dev}}
\{{ Provides: libqpid-proton-proactor-dev}}
{{Depends: libqpid-proton11-dev (>= ${binary:Version}),
libqpid-proton-proactor1 (= ${binary:Version}), $\{misc:Depends}}}
{{...}}
and is missing a dep on {{libqpid-proton-core10-dev}} which provides the
missing file.
> Cannot build Dispatch using the Debian PPA Proton packages
> --
>
> Key: PROTON-2341
> URL: https://issues.apache.org/jira/browse/PROTON-2341
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, release
>Affects Versions: proton-c-0.33.0
> Environment: Ubuntu Focal
>Reporter: Jiri Daněk
>Assignee: Irina Boverman
>Priority: Major
>
> I am installing Proton from PPA
> {noformat}
> $ sudo add-apt-repository ppa:qpid/testing && sudo apt-get update
> $ sudo apt install -y libqpid-proton-proactor1-dev python3-qpid-proton
> {noformat}
> I run Dispatch compilation, but I get error
> {noformat}
> -- Found Proton:
> optimized;/usr/lib/x86_64-linux-gnu/libqpid-proton.so;debug;/usr/lib/x86_64-linux-gnu/libqpid-proton.so
> (found version "0.33.0")
> {noformat}
> (notice that the .so mentioned in this cmake output does not actually exist
> in the package, there it is named with extra .10 at the end.)
> {noformat}
> [...]
> [ 81%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> [ 83%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http2/http2_adaptor.c.o
> make[3]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/libqpid-proton-core.so', needed by
> 'src/libqpid-dispatch.so'. Stop.
> make[2]: *** [CMakeFiles/Makefile2:1072:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:1296: docs/CMakeFiles/docs.dir/rule] Error
> 2
> make: *** [Makefile:662: docs] Error 2
> Error: Process completed with exit code 2.
> {noformat}
> To workaround this, I have to do
> {noformat}
> sudo ln -s /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so.10
> /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so
> {noformat}
> and then the build succeeds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2341) Cannot build Dispatch using the Debian PPA Proton packages
[
https://issues.apache.org/jira/browse/PROTON-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340911#comment-17340911
]
Kim van der Riet edited comment on PROTON-2341 at 5/7/21, 4:01 PM:
---
According to the debian/control file:
{{Package: libqpid-proton-proactor1-dev}}
\{{ Provides: libqpid-proton-proactor-dev}}
{{Depends: libqpid-proton11-dev (>= ${binary:Version}),
libqpid-proton-proactor1 (= ${binary:Version}), $\{misc:Depends}}}
{{...}}
and is missing a dep on {{libqpid-proton-core10-dev}} which provides the
missing file.
was (Author: kpvdr):
According to the debian/control file:
Package: libqpid-proton-proactor1-dev
Provides: libqpid-proton-proactor-dev
> Cannot build Dispatch using the Debian PPA Proton packages
> --
>
> Key: PROTON-2341
> URL: https://issues.apache.org/jira/browse/PROTON-2341
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, release
>Affects Versions: proton-c-0.33.0
> Environment: Ubuntu Focal
>Reporter: Jiri Daněk
>Assignee: Irina Boverman
>Priority: Major
>
> I am installing Proton from PPA
> {noformat}
> $ sudo add-apt-repository ppa:qpid/testing && sudo apt-get update
> $ sudo apt install -y libqpid-proton-proactor1-dev python3-qpid-proton
> {noformat}
> I run Dispatch compilation, but I get error
> {noformat}
> -- Found Proton:
> optimized;/usr/lib/x86_64-linux-gnu/libqpid-proton.so;debug;/usr/lib/x86_64-linux-gnu/libqpid-proton.so
> (found version "0.33.0")
> {noformat}
> (notice that the .so mentioned in this cmake output does not actually exist
> in the package, there it is named with extra .10 at the end.)
> {noformat}
> [...]
> [ 81%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> [ 83%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http2/http2_adaptor.c.o
> make[3]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/libqpid-proton-core.so', needed by
> 'src/libqpid-dispatch.so'. Stop.
> make[2]: *** [CMakeFiles/Makefile2:1072:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:1296: docs/CMakeFiles/docs.dir/rule] Error
> 2
> make: *** [Makefile:662: docs] Error 2
> Error: Process completed with exit code 2.
> {noformat}
> To workaround this, I have to do
> {noformat}
> sudo ln -s /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so.10
> /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so
> {noformat}
> and then the build succeeds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2341) Cannot build Dispatch using the Debian PPA Proton packages
[
https://issues.apache.org/jira/browse/PROTON-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340911#comment-17340911
]
Kim van der Riet commented on PROTON-2341:
--
According to the debian/control file:
Package: libqpid-proton-proactor1-dev
Provides: libqpid-proton-proactor-dev
> Cannot build Dispatch using the Debian PPA Proton packages
> --
>
> Key: PROTON-2341
> URL: https://issues.apache.org/jira/browse/PROTON-2341
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, release
>Affects Versions: proton-c-0.33.0
> Environment: Ubuntu Focal
>Reporter: Jiri Daněk
>Assignee: Irina Boverman
>Priority: Major
>
> I am installing Proton from PPA
> {noformat}
> $ sudo add-apt-repository ppa:qpid/testing && sudo apt-get update
> $ sudo apt install -y libqpid-proton-proactor1-dev python3-qpid-proton
> {noformat}
> I run Dispatch compilation, but I get error
> {noformat}
> -- Found Proton:
> optimized;/usr/lib/x86_64-linux-gnu/libqpid-proton.so;debug;/usr/lib/x86_64-linux-gnu/libqpid-proton.so
> (found version "0.33.0")
> {noformat}
> (notice that the .so mentioned in this cmake output does not actually exist
> in the package, there it is named with extra .10 at the end.)
> {noformat}
> [...]
> [ 81%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> [ 83%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http2/http2_adaptor.c.o
> make[3]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/libqpid-proton-core.so', needed by
> 'src/libqpid-dispatch.so'. Stop.
> make[2]: *** [CMakeFiles/Makefile2:1072:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:1296: docs/CMakeFiles/docs.dir/rule] Error
> 2
> make: *** [Makefile:662: docs] Error 2
> Error: Process completed with exit code 2.
> {noformat}
> To workaround this, I have to do
> {noformat}
> sudo ln -s /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so.10
> /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so
> {noformat}
> and then the build succeeds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2341) Cannot build Dispatch using the Debian PPA Proton packages
[
https://issues.apache.org/jira/browse/PROTON-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340911#comment-17340911
]
Kim van der Riet edited comment on PROTON-2341 at 5/7/21, 3:58 PM:
---
According to the debian/control file:
Package: libqpid-proton-proactor1-dev
Provides: libqpid-proton-proactor-dev
was (Author: kpvdr):
According to the debian/control file:
Package: libqpid-proton-proactor1-dev
Provides: libqpid-proton-proactor-dev
> Cannot build Dispatch using the Debian PPA Proton packages
> --
>
> Key: PROTON-2341
> URL: https://issues.apache.org/jira/browse/PROTON-2341
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, release
>Affects Versions: proton-c-0.33.0
> Environment: Ubuntu Focal
>Reporter: Jiri Daněk
>Assignee: Irina Boverman
>Priority: Major
>
> I am installing Proton from PPA
> {noformat}
> $ sudo add-apt-repository ppa:qpid/testing && sudo apt-get update
> $ sudo apt install -y libqpid-proton-proactor1-dev python3-qpid-proton
> {noformat}
> I run Dispatch compilation, but I get error
> {noformat}
> -- Found Proton:
> optimized;/usr/lib/x86_64-linux-gnu/libqpid-proton.so;debug;/usr/lib/x86_64-linux-gnu/libqpid-proton.so
> (found version "0.33.0")
> {noformat}
> (notice that the .so mentioned in this cmake output does not actually exist
> in the package, there it is named with extra .10 at the end.)
> {noformat}
> [...]
> [ 81%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> [ 83%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http2/http2_adaptor.c.o
> make[3]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/libqpid-proton-core.so', needed by
> 'src/libqpid-dispatch.so'. Stop.
> make[2]: *** [CMakeFiles/Makefile2:1072:
> src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:1296: docs/CMakeFiles/docs.dir/rule] Error
> 2
> make: *** [Makefile:662: docs] Error 2
> Error: Process completed with exit code 2.
> {noformat}
> To workaround this, I have to do
> {noformat}
> sudo ln -s /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so.10
> /usr/lib/x86_64-linux-gnu/libqpid-proton-core.so
> {noformat}
> and then the build succeeds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved PROTON-2237. -- Resolution: Fixed > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned PROTON-2237: Assignee: Kim van der Riet > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2298) Disable default running of c-threadersiser test
Kim van der Riet created PROTON-2298: Summary: Disable default running of c-threadersiser test Key: PROTON-2298 URL: https://issues.apache.org/jira/browse/PROTON-2298 Project: Qpid Proton Issue Type: Task Reporter: Kim van der Riet By default, the c-threadersiser test is enabled depending on availability of pthreads. This test, being a little unreliable, should be disabled by default, and enabled only when required for testing. This may be reversed at a future time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2289) cpp-connect_config_test fails on fedora:latest: 1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
Kim van der Riet created PROTON-2289:
Summary: cpp-connect_config_test fails on fedora:latest:
1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
Key: PROTON-2289
URL: https://issues.apache.org/jira/browse/PROTON-2289
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Kim van der Riet
The following tests fail with the same error message:
* test_tls
* test_tls_default_fail
* test_tls_external
* test_tls_plain
Error message:
{noformat}
/foo/proton/cpp/src/connect_config_test.cpp:193: unexpected error
amqp:connection:framing-error: SSL Failure: error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher
{noformat}
In addition, valgrind finds a memory loss error which is possibly associated
with these errors:
{noformat}
23: ==2466== 149,899 (1,408 direct, 148,491 indirect) bytes in 1 blocks are
definitely lost in loss record 760 of 764
23: ==2466==at 0x483CAE9: calloc (vg_replace_malloc.c:760)
23: ==2466==by 0x4E3A0D5: pn_listener (epoll.c:1635)
23: ==2466==by 0x487CFF8:
proton::container::impl::listen_common_lh(std::__cxx11::basic_string, std::allocator > const&)
(proactor_container_impl.cpp:434)
23: ==2466==by 0x487D220:
proton::container::impl::listen(std::__cxx11::basic_string, std::allocator > const&, proton::listen_handler&)
(proactor_container_impl.cpp:456)
23: ==2466==by 0x487B17C:
proton::container::listen(std::__cxx11::basic_string, std::allocator > const&, proton::listen_handler&)
(container.cpp:90)
23: ==2466==by 0x40CE7B: (anonymous
namespace)::test_handler::on_container_start(proton::container&)
(connect_config_test.cpp:180)
23: ==2466==by 0x4904ACE: __pthread_once_slow (in
/usr/lib64/libpthread-2.31.so)
23: ==2466==by 0x487F539: __gthread_once (gthr-default.h:700)
23: ==2466==by 0x487F539: call_once (mutex:729)
23: ==2466==by 0x487F539: proton::container::impl::run(int)
(proactor_container_impl.cpp:794)
23: ==2466==by 0x40D2D2: (anonymous
namespace)::test_tls_default_fail::run() (connect_config_test.cpp:345)
23: ==2466==by 0x40BD4B: main (connect_config_test.cpp:432)
{noformat}
and which occurs once for each of the tests which failed above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2274) Threaderciser test valgrind error
Kim van der Riet created PROTON-2274:
Summary: Threaderciser test valgrind error
Key: PROTON-2274
URL: https://issues.apache.org/jira/browse/PROTON-2274
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Kim van der Riet
A recent test of Proton [1] revealed a threadersiser valgrind error:
{noformat}
test 7
Start 7: c-threaderciser
7: Test command: /opt/pyenv/shims/python3
"/home/travis/build/apache/qpid-proton/scripts/env.py" "--"
"TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
--error-exitcode=42 --quiet
--suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
"/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full" "--error-exitcode=42"
"--quiet"
"--suppressions=/home/travis/build/apache/qpid-proton/tests/valgrind.supp"
"/home/travis/build/apache/qpid-proton/build/c/tests/c-threaderciser"
7: Test timeout computed to be: 360
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
7: ==12926== 128,678 (1,128 direct, 127,550 indirect) bytes in 1 blocks are
definitely lost in loss record 165 of 165
7: ==12926== at 0x483B7F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
7: ==12926== by 0x10B110: listener_ctx_new (threaderciser.c:264)
7: ==12926== by 0x10B110: lpool_listen.part.0 (threaderciser.c:283)
7: ==12926== by 0x10B88B: lpool_listen (threaderciser.c:380)
7: ==12926== by 0x10B88B: global_do_stuff (threaderciser.c:380)
7: ==12926== by 0x10BBD7: user_thread (threaderciser.c:398)
7: ==12926== by 0x48AF608: start_thread (pthread_create.c:477)
7: ==12926== by 0x49EB102: clone (clone.S:95)
7: ==12926==
7/48 Test #7: c-threaderciser ..***Failed 2.14 sec
{noformat}
[1] [https://travis-ci.org/github/apache/qpid-proton/jobs/721459983]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-139) Update QIT to use Python 3 rather than Python 2
[ https://issues.apache.org/jira/browse/QPIDIT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-139. - Resolution: Fixed > Update QIT to use Python 3 rather than Python 2 > --- > > Key: QPIDIT-139 > URL: https://issues.apache.org/jira/browse/QPIDIT-139 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Complex Types Test, AMQP Large Content Test, AMQP > Types Test, Installation, JMS Headers and Properties Test, JMS Message Test >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Upgrade the tests to use Python 3 rather than Python 2. The shims will still > run both. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2244) [Proton-c] Encoder error for array of lists where first list in array is empty
[
https://issues.apache.org/jira/browse/PROTON-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved PROTON-2244.
--
Resolution: Fixed
> [Proton-c] Encoder error for array of lists where first list in array is empty
> --
>
> Key: PROTON-2244
> URL: https://issues.apache.org/jira/browse/PROTON-2244
> Project: Qpid Proton
> Issue Type: Task
> Components: proton-c
> Reporter: Kim van der Riet
>Priority: Major
>
> AMQP encodes arrays with a single element constructor which should be
> identical for all elements in the array. However, if an array of lists is
> constructed in which the first list is empty, then the AMQP empty list
> constructor is used in the array, and the following lists which may be
> non-empty, will not be decoded correctly.
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> d1 = proton.Data()
> >>> d1.put_py_array(a)
> >>> d1.encode().hex()
> 'f0002a000345000a000355015502550300130003a103616161a103626262a103636363'
> {noformat}
> which, when broken down into parts, looks as follows:
> {noformat}
> f0 02a 0003 45 <-- Array constructor, size=0x2a, len=3, type=empty
> list
> ^^--- Empty list constructor
> 000a 0003 5501 5502 5503 <- data for [1,2,3]
> 0013 0003 a103616161 a103626262 a103636363 <-- data for ['aaa',
> 'bbb', 'ccc']
> {noformat}
> When decoded, this is being interpreted as an array of empty lists:
> {noformat}
> >>> d2 = proton.Data()
> >>> d2.decode(d1.encode())
> 10
> >>> d2.get_py_array()
> Array(UNDESCRIBED, 24, [], [], [])
> {noformat}
> When a mis-encoded array is used in the body of a message and is decoded, an
> error results:
> {noformat}
> >>> import proton
> >>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3],
> >>> ['aaa', 'bbb', 'ccc'])
> >>> m1 = proton.Message(body=a)
> >>> m1
> Message(priority=4, body=Array(UNDESCRIBED, 24, [], [1, 2, 3], ['aaa', 'bbb',
> 'ccc']))
> >>> m2 = proton.Message()
> >>> m2.decode(m1.encode())
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 488, in decode
> self._check(pn_message_decode(self._msg, data))
> File
> "/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
> line 87, in _check
> raise exc("[%s]: %s" % (err, pn_error_text(pn_message_error(self._msg
> proton._exceptions.MessageException: [-6]: data error: (null)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2249) [Proton-c] AMQP char type does not handle null chars correctly from pn_inspect()
[
https://issues.apache.org/jira/browse/PROTON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2249:
-
Summary: [Proton-c] AMQP char type does not handle null chars correctly
from pn_inspect() (was: [Proton-c] AMQP char type does not always print
correctly from pn_inspect())
> [Proton-c] AMQP char type does not handle null chars correctly from
> pn_inspect()
>
>
> Key: PROTON-2249
> URL: https://issues.apache.org/jira/browse/PROTON-2249
> Project: Qpid Proton
> Issue Type: Bug
> Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_inspect()}}* method returns a string representation of the
> inspected AMQP type.
> While testing an array of type char in which the first char had value 0x0, it
> was observed that this method is not correctly printing the array, but is
> being truncated:
> {noformat}
> "@PN_CHAR["
> {noformat}
> and prevents effective checking of the array contents in the test.
> The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
> method. The use of the {{%c}} formatting code to print the char is causing
> null chars to terminate the string which is being treated as a c-string. The
> following suggested change fixes this issue and prefixes each char with 'U'
> to indicate it is UTF-32:
> {noformat}
> diff --git a/c/src/core/codec.c b/c/src/core/codec.c
> index b50f286b..1f9185f7 100644
> --- a/c/src/core/codec.c
> +++ b/c/src/core/codec.c
> @@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
> case PN_INT:
> return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
> case PN_CHAR:
> - return pn_string_addf(str, "%c", atom->u.as_char);
> + if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
> atom->u.as_char);
> + return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
> case PN_ULONG:
> return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
> case PN_LONG:
> {noformat}
> and the array prints as:
> {noformat}
> "@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
> {noformat}
> The following are improved:
> * Each char is surrounded by single quotes {{'\''}}
> * Each char is prefixed by 'U' to indicate it is UTF-32 (see
> [https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
> * Printable chars print as the char itself, non-printable chars print as the
> hex ordinal value.
> Thoughts?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2249) [Proton-c] AMQP char type does not always print correctly from pn_inspect()
[
https://issues.apache.org/jira/browse/PROTON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2249:
-
Description:
The *{{pn_inspect()}}* method returns a string representation of the inspected
AMQP type.
While testing an array of type char in which the first char had value 0x0, it
was observed that this method is not correctly printing the array, but is being
truncated:
{noformat}
"@PN_CHAR["
{noformat}
and prevents effective checking of the array contents in the test.
The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
method. The use of the {{%c}} formatting code to print the char is causing null
chars to terminate the string which is being treated as a c-string. The
following suggested change fixes this issue and prefixes each char with 'U' to
indicate it is UTF-32:
{noformat}
diff --git a/c/src/core/codec.c b/c/src/core/codec.c
index b50f286b..1f9185f7 100644
--- a/c/src/core/codec.c
+++ b/c/src/core/codec.c
@@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
case PN_INT:
return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
case PN_CHAR:
- return pn_string_addf(str, "%c", atom->u.as_char);
+ if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
atom->u.as_char);
+ return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
case PN_ULONG:
return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
case PN_LONG:
{noformat}
and the array prints as:
{noformat}
"@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
{noformat}
The following are improved:
* Each char is surrounded by single quotes {{'\''}}
* Each char is prefixed by 'U' to indicate it is UTF-32 (see
[https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
* Printable chars print as the char itself, non-printable chars print as the
hex ordinal value.
Thoughts?
was:
The *{{pn_inspect()}}* method returns a string representation of the inspected
AMQP type.
While testing an array of type char in which the first char had value 0x0, it
was observed that this method is not correctly printing the array, but is being
truncated:
{noformat}
"@PN_CHAR["
{noformat}
and prevents effective checking of the array contents in the test.
The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
method. The following suggested change fixes this issue and prefixes each char
with 'U' to indicate it is UTF-32:
{noformat}
diff --git a/c/src/core/codec.c b/c/src/core/codec.c
index b50f286b..1f9185f7 100644
--- a/c/src/core/codec.c
+++ b/c/src/core/codec.c
@@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
case PN_INT:
return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
case PN_CHAR:
- return pn_string_addf(str, "%c", atom->u.as_char);
+ if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
atom->u.as_char);
+ return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
case PN_ULONG:
return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
case PN_LONG:
{noformat}
and the array prints as:
{noformat}
"@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
{noformat}
The following are improved:
* Each char is surrounded by single quotes {{'\''}}
* Each char is prefixed by 'U' to indicate it is UTF-32 (see
[https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
* Printable chars print as the char itself, non-printable chars print as the
hex ordinal value.
Thoughts?
> [Proton-c] AMQP char type does not always print correctly from pn_inspect()
> -------
>
> Key: PROTON-2249
> URL: https://issues.apache.org/jira/browse/PROTON-2249
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_inspect()}}* method returns a string representation of the
> inspected AMQP type.
> While testing an array of type char in which the first char had value 0x0, it
> was observed that this method is not correctly printing the array, but is
> being truncated:
> {noformat}
> "@PN_CHAR["
> {noformat}
> and prevents effective checking of the array contents in the test.
> The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
> method. The use of the {{%c}} formatting code to print the char is causing
> null chars to terminate the string which is being treated as a c-string. The
> foll
[jira] [Updated] (PROTON-2249) [Proton-c] AMQP char type does not always print correctly from pn_inspect()
[
https://issues.apache.org/jira/browse/PROTON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2249:
-
Description:
The *{{pn_inspect()}}* method returns a string representation of the inspected
AMQP type.
While testing an array of type char in which the first char had value 0x0, it
was observed that this method is not correctly printing the array, but is being
truncated:
{noformat}
"@PN_CHAR["
{noformat}
and prevents effective checking of the array contents in the test.
The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
method. The following suggested change fixes this issue and prefixes each char
with 'U' to indicate it is UTF-32:
{noformat}
diff --git a/c/src/core/codec.c b/c/src/core/codec.c
index b50f286b..1f9185f7 100644
--- a/c/src/core/codec.c
+++ b/c/src/core/codec.c
@@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
case PN_INT:
return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
case PN_CHAR:
- return pn_string_addf(str, "%c", atom->u.as_char);
+ if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
atom->u.as_char);
+ return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
case PN_ULONG:
return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
case PN_LONG:
{noformat}
and the array prints as:
{noformat}
"@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
{noformat}
The following are improved:
* Each char is surrounded by single quotes {{'\''}}
* Each char is prefixed by 'U' to indicate it is UTF-32 (see
[https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
* Printable chars print as the char itself, non-printable chars print as the
hex ordinal value.
Thoughts?
was:
The *{{pn_inspect()}}* method returns a string representation of the inspected
AMQP type.
While testing an array of type char in which the first char had value 0x0, it
was observed that this method is not correctly printing the array, but is being
truncated:
{noformat}
"@PN_CHAR["
{noformat}
and prevents effective checking of the array contents in the test.
The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
method. The following suggested change fixes this issue and prefixes each char
with 'U' to indicate it is UTF-32:
{noformat}
diff --git a/c/src/core/codec.c b/c/src/core/codec.c
index b50f286b..1f9185f7 100644
--- a/c/src/core/codec.c
+++ b/c/src/core/codec.c
@@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
case PN_INT:
return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
case PN_CHAR:
- return pn_string_addf(str, "%c", atom->u.as_char);
+ if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
atom->u.as_char);
+ return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
case PN_ULONG:
return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
case PN_LONG:
{noformat}
and the array prints as:
{noformat}
"@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
{noformat}
The following are improved:
* Each char is surrounded by single quotes {{'\''}}
* Each char is prefixed by 'U' to indicate it is UTF-32 (see
[https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
* Printable chars print as the char itself, non-printable chars print as the
hex ordinal value.
Thoughts?
> [Proton-c] AMQP char type does not always print correctly from pn_inspect()
> -------
>
> Key: PROTON-2249
> URL: https://issues.apache.org/jira/browse/PROTON-2249
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_inspect()}}* method returns a string representation of the
> inspected AMQP type.
> While testing an array of type char in which the first char had value 0x0, it
> was observed that this method is not correctly printing the array, but is
> being truncated:
> {noformat}
> "@PN_CHAR["
> {noformat}
> and prevents effective checking of the array contents in the test.
> The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
> method. The following suggested change fixes this issue and prefixes each
> char with 'U' to indicate it is UTF-32:
> {noformat}
> diff --git a/c/src/core/codec.c b/c/src/core/codec.c
> index b50f286b..1f9185f7 100644
> --- a/c/src/core/codec.c
> +++ b/c/src/core/codec.c
> @@ -129,7 +129,8 @@ int pni_in
[jira] [Created] (PROTON-2249) [Proton-c] AMQP char type does not always print correctly from pn_inspect()
Kim van der Riet created PROTON-2249:
Summary: [Proton-c] AMQP char type does not always print correctly
from pn_inspect()
Key: PROTON-2249
URL: https://issues.apache.org/jira/browse/PROTON-2249
Project: Qpid Proton
Issue Type: Bug
Reporter: Kim van der Riet
The *{{pn_inspect()}}* method returns a string representation of the inspected
AMQP type.
While testing an array of type char in which the first char had value 0x0, it
was observed that this method is not correctly printing the array, but is being
truncated:
{noformat}
"@PN_CHAR["
{noformat}
and prevents effective checking of the array contents in the test.
The formatting of simple AMQP types is set in the *{{pni_inspect_atom()}}*
method. The following suggested change fixes this issue and prefixes each char
with 'U' to indicate it is UTF-32:
{noformat}
diff --git a/c/src/core/codec.c b/c/src/core/codec.c
index b50f286b..1f9185f7 100644
--- a/c/src/core/codec.c
+++ b/c/src/core/codec.c
@@ -129,7 +129,8 @@ int pni_inspect_atom(pn_atom_t *atom, pn_string_t *str)
case PN_INT:
return pn_string_addf(str, "%" PRIi32, atom->u.as_int);
case PN_CHAR:
- return pn_string_addf(str, "%c", atom->u.as_char);
+ if (isprint(atom->u.as_char)) return pn_string_addf(str, "U'%c'",
atom->u.as_char);
+ return pn_string_addf(str, "U'\\x%" PRIx32 "'", atom->u.as_char);
case PN_ULONG:
return pn_string_addf(str, "%" PRIu64, atom->u.as_ulong);
case PN_LONG:
{noformat}
and the array prints as:
{noformat}
"@PN_CHAR[U'\x0', U'5', U'a', U'Z', U'\x7f']"
{noformat}
The following are improved:
* Each char is surrounded by single quotes {{'\''}}
* Each char is prefixed by 'U' to indicate it is UTF-32 (see
[https://en.cppreference.com/w/cpp/language/character_literal)|https://en.cppreference.com/w/cpp/language/character_literal]
* Printable chars print as the char itself, non-printable chars print as the
hex ordinal value.
Thoughts?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2248) [Proton-c] Codec pn_data_vfill() method has symbol and string types interchanged.
[
https://issues.apache.org/jira/browse/PROTON-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2248:
-
Description:
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The function documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
was:
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The method documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
> [Proton-c] Codec pn_data_vfill() method has symbol and string types
> interchanged.
> -
>
> Key: PROTON-2248
> URL: https://issues.apache.org/jira/browse/PROTON-2248
> Project: Qpid Proton
> Issue Type: Bug
> Reporter: Kim van der Riet
>Priority: Major
>
> The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string
> types interchanged. The function documentation states:
> {noformat}
> /* Format codes:
>code: AMQP-type (arguments)
>...
>S: symbol (char*)
>s: string (char*)
>...
> */
> {noformat}
> but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
> {noformat}
> if (code == 'S') {
> err = pn_data_put_string(data, pn_bytes(size, start));
> } else {
> err = pn_data_put_symbol(data, pn_bytes(size, start));
> }
> {noformat}
> Guidance is needed on whether to fix the reversal and keep the stated codes,
> or reverse the codes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2248) [Proton-c] Codec pn_data_vfill() method has symbol and string types interchanged.
Kim van der Riet created PROTON-2248:
Summary: [Proton-c] Codec pn_data_vfill() method has symbol and
string types interchanged.
Key: PROTON-2248
URL: https://issues.apache.org/jira/browse/PROTON-2248
Project: Qpid Proton
Issue Type: Bug
Reporter: Kim van der Riet
The *{{pn_data_vfill()}}* method in codec.c:571 has the symbol and string types
interchanged. The method documentation states:
{noformat}
/* Format codes:
code: AMQP-type (arguments)
...
S: symbol (char*)
s: string (char*)
...
*/
{noformat}
but uses these the other way around, ie {{s}} for symbol and {{S}} for string:
{noformat}
if (code == 'S') {
err = pn_data_put_string(data, pn_bytes(size, start));
} else {
err = pn_data_put_symbol(data, pn_bytes(size, start));
}
{noformat}
Guidance is needed on whether to fix the reversal and keep the stated codes, or
reverse the codes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2244) [Proton-c] Encoder error for array of lists where first list in array is empty
Kim van der Riet created PROTON-2244:
Summary: [Proton-c] Encoder error for array of lists where first
list in array is empty
Key: PROTON-2244
URL: https://issues.apache.org/jira/browse/PROTON-2244
Project: Qpid Proton
Issue Type: Task
Components: proton-c
Reporter: Kim van der Riet
AMQP encodes arrays with a single element constructor which should be identical
for all elements in the array. However, if an array of lists is constructed in
which the first list is empty, then the AMQP empty list constructor is used in
the array, and the following lists which may be non-empty, will not be decoded
correctly.
{noformat}
>>> import proton
>>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3], ['aaa',
>>> 'bbb', 'ccc'])
>>> d1 = proton.Data()
>>> d1.put_py_array(a)
>>> d1.encode().hex()
'f0002a000345000a000355015502550300130003a103616161a103626262a103636363'
{noformat}
which, when broken down into parts, looks as follows:
{noformat}
f0 02a 0003 45 <-- Array constructor, size=0x2a, len=3, type=empty list
^^--- Empty list constructor
000a 0003 5501 5502 5503 <- data for [1,2,3]
0013 0003 a103616161 a103626262 a103636363 <-- data for ['aaa', 'bbb',
'ccc']
{noformat}
When decoded, this is being interpreted as an array of empty lists:
{noformat}
>>> d2 = proton.Data()
>>> d2.decode(d1.encode())
10
>>> d2.get_py_array()
Array(UNDESCRIBED, 24, [], [], [])
{noformat}
When a mis-encoded array is used in the body of a message and is decoded, an
error results:
{noformat}
>>> import proton
>>> a = proton.Array(proton.UNDESCRIBED, proton.Data.LIST, [], [1,2,3], ['aaa',
>>> 'bbb', 'ccc'])
>>> m1 = proton.Message(body=a)
>>> m1
Message(priority=4, body=Array(UNDESCRIBED, 24, [], [1, 2, 3], ['aaa', 'bbb',
'ccc']))
>>> m2 = proton.Message()
>>> m2.decode(m1.encode())
Traceback (most recent call last):
File "", line 1, in
File
"/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
line 488, in decode
self._check(pn_message_decode(self._msg, data))
File
"/home/kvdr/RedHat/install/lib64/proton/bindings/python3/proton/_message.py",
line 87, in _check
raise exc("[%s]: %s" % (err, pn_error_text(pn_message_error(self._msg
proton._exceptions.MessageException: [-6]: data error: (null)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-142) Remove complex types from amqp_types_test, rename to amqp_simple_types_test
Kim van der Riet created QPIDIT-142: --- Summary: Remove complex types from amqp_types_test, rename to amqp_simple_types_test Key: QPIDIT-142 URL: https://issues.apache.org/jira/browse/QPIDIT-142 Project: Apache QPID Interoperability Test Suite Issue Type: Task Components: AMQP Types Test Reporter: Kim van der Riet Assignee: Kim van der Riet amqp_types_test contains a few arbitrary maps and lists. However, these complex AMQP types (which can be arbitrarily deeply encoded) are now covered in the amqp_complex_types_test. In addition, the shims for these complex types were not recursively encoding the subtypes contained in these types, but were using the string representation of the subtypes. This makes them of limited usefulness. I suggest that these tests be removed. In addition, I suggest that amqp_types_test be renamed to amqp_simple_types_test to help clearly distinguish it from the complex type test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-135) Absence of Python 3 not detected
[
https://issues.apache.org/jira/browse/QPIDIT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPIDIT-135.
-
Resolution: Fixed
> Absence of Python 3 not detected
>
>
> Key: QPIDIT-135
> URL: https://issues.apache.org/jira/browse/QPIDIT-135
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.1.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
>
> The presence of Python 2.7 is required for QIT, Python 3.x is not required
> but recommended. However, the absence of Python 3.x is not detected during
> installation, and the {{PYTHON3_PATH}} environment variable is created, and
> which contains Pyhton 2.7 paths.
> The install needs to detect the presence of Python 3.x and based on its
> finding:
> * Set the {{PYTHON3_PATH}} environmet variable correctly or unset it;
> * Automatically enable/disable the Python3 shims.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-135) Absence of Python 3 not detected
[
https://issues.apache.org/jira/browse/QPIDIT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPIDIT-135:
Affects Version/s: (was: 0.1.0)
0.2.0
> Absence of Python 3 not detected
>
>
> Key: QPIDIT-135
> URL: https://issues.apache.org/jira/browse/QPIDIT-135
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.2.0
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
>
> The presence of Python 2.7 is required for QIT, Python 3.x is not required
> but recommended. However, the absence of Python 3.x is not detected during
> installation, and the {{PYTHON3_PATH}} environment variable is created, and
> which contains Pyhton 2.7 paths.
> The install needs to detect the presence of Python 3.x and based on its
> finding:
> * Set the {{PYTHON3_PATH}} environmet variable correctly or unset it;
> * Automatically enable/disable the Python3 shims.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-100) Check status of broker between tests
[ https://issues.apache.org/jira/browse/QPIDIT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-100: Affects Version/s: (was: 0.1.0) 0.2.0 > Check status of broker between tests > > > Key: QPIDIT-100 > URL: https://issues.apache.org/jira/browse/QPIDIT-100 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Minor > > If the broker should stop during a test, the test will continue to try to run > all of the tests. A check should be made between each test that will ensure > the broker is still present. Perhaps a check of the PID will suffice. > Note that for some broker configurations (such as multi-node dispatch router > tests), multiple nodes and/or brokers may be present, and all of them must be > checked. > If one or more of the test nodes is missing, the test should immediately > terminate with an error message. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-133) [complex_types_test]: Remove float types inf, +inf, -inf because of RHEL7 Proton bug
[ https://issues.apache.org/jira/browse/QPIDIT-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-133. --- Resolution: Fixed > [complex_types_test]: Remove float types inf, +inf, -inf because of RHEL7 > Proton bug > > > Key: QPIDIT-133 > URL: https://issues.apache.org/jira/browse/QPIDIT-133 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > A bug in RHEL7 / CentOS7 Proton causes an overflow error when using float > literals '+inf' or '-inf'. The error does not occur in double values, nor for > literal 'NaN'. See PROTON-1149 and PROTON-1838. > The amqp_complex_types_test uses JSON files to represent the values of the > test. However, these files do not allow for comments, so it is not possible > to comment out parts of the data. Data is either present or not. > In order to prevent this failure from causing the test to fail, remove the > test values 'inf', '+inf' and '-inf' from the test data until this bug is > fixed in Proton. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-141) Incorrect handling of binary types
[ https://issues.apache.org/jira/browse/QPIDIT-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-141: Affects Version/s: (was: 0.1.0) 0.2.0 > Incorrect handling of binary types > -- > > Key: QPIDIT-141 > URL: https://issues.apache.org/jira/browse/QPIDIT-141 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, JMS Headers and Properties Test, JMS > Message Test >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > When binary test values are sent using JSON to the shims, they are converted > to strings, as JSON cannot handle binary values. With the conversion of QIT > tests to Python 3, the encoding of binary to strings has become an issue > (under Py2, binary and str were synonymous). > It is probably best that the binary be encoded into base64 and then converted > to a string for use as a value in JSON. Each shim would then have to decode > these values back to an appropriate binary value. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-139) Update QIT to use Python 3 rather than Python 2
[ https://issues.apache.org/jira/browse/QPIDIT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-139: Affects Version/s: (was: 0.1.0) 0.2.0 > Update QIT to use Python 3 rather than Python 2 > --- > > Key: QPIDIT-139 > URL: https://issues.apache.org/jira/browse/QPIDIT-139 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Complex Types Test, AMQP Large Content Test, AMQP > Types Test, Installation, JMS Headers and Properties Test, JMS Message Test >Affects Versions: 0.2.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Upgrade the tests to use Python 3 rather than Python 2. The shims will still > run both. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-139) Update QIT to use Python 3 rather than Python 2
[ https://issues.apache.org/jira/browse/QPIDIT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-139: Affects Version/s: 0.1.0 > Update QIT to use Python 3 rather than Python 2 > --- > > Key: QPIDIT-139 > URL: https://issues.apache.org/jira/browse/QPIDIT-139 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Complex Types Test, AMQP Large Content Test, AMQP > Types Test, Installation, JMS Headers and Properties Test, JMS Message Test >Affects Versions: 0.1.0 > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Upgrade the tests to use Python 3 rather than Python 2. The shims will still > run both. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPID-8430. -- Resolution: Fixed > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-141) Incorrect handling of binary types
Kim van der Riet created QPIDIT-141: --- Summary: Incorrect handling of binary types Key: QPIDIT-141 URL: https://issues.apache.org/jira/browse/QPIDIT-141 Project: Apache QPID Interoperability Test Suite Issue Type: Bug Components: AMQP Types Test, JMS Headers and Properties Test, JMS Message Test Affects Versions: 0.1.0 Reporter: Kim van der Riet Assignee: Kim van der Riet When binary test values are sent using JSON to the shims, they are converted to strings, as JSON cannot handle binary values. With the conversion of QIT tests to Python 3, the encoding of binary to strings has become an issue (under Py2, binary and str were synonymous). It is probably best that the binary be encoded into base64 and then converted to a string for use as a value in JSON. Each shim would then have to decode these values back to an appropriate binary value. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated PROTON-2237: - Description: The AMQP 1.0 spec allows only string keys for message properties. Proton's Python binding has a method (_message.py:91 _check_property_keys()) for checking message property keys, but it does not handle all cases correctly: # Proton types Symbol and Char are derived from string, and are allowed in the test. This results in an illegal encoding. # Because in Python 2, many coders carelessly use string literals without the required u'' prefix (and thus results in a bytes type), bytes types are converted to unicode string types. However, the encode() function is being used, which simply returns a binary type in Python 2 and raises an error in Python 3. This should probably be the decode() method, which returns a string and works for both Python 2 and 3. was: The AMQP 1.0 spec allows only string keys for message properties. Proton's Python binding has a method (_message.py:91 _check_property_keys()) for checking message property keys, but it does not handle all cases correctly: # Proton types Symbol and Char are derived from string, and are allowed in the test. This results in an illegal encoding. # Because in Python 2, many coders carelessly use string literals without the required u'' prefix (and thus results in a bytes type), bytes types are converted to unicode string types. However, the encode() function is being used, which simply returns a binary type in Python 2 and raises an error in Python 3. This should probably be the decode() method, which works for both Python 2 and 3. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding > Reporter: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2237) [python] Non-string message property keys not handled correctly
Kim van der Riet created PROTON-2237: Summary: [python] Non-string message property keys not handled correctly Key: PROTON-2237 URL: https://issues.apache.org/jira/browse/PROTON-2237 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Kim van der Riet The AMQP 1.0 spec allows only string keys for message properties. Proton's Python binding has a method (_message.py:91 _check_property_keys()) for checking message property keys, but it does not handle all cases correctly: # Proton types Symbol and Char are derived from string, and are allowed in the test. This results in an illegal encoding. # Because in Python 2, many coders carelessly use string literals without the required u'' prefix (and thus results in a bytes type), bytes types are converted to unicode string types. However, the encode() function is being used, which simply returns a binary type in Python 2 and raises an error in Python 3. This should probably be the decode() method, which works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2236) [proton-j] Error message when decoding illegal message properties key is unhelpful
Kim van der Riet created PROTON-2236:
Summary: [proton-j] Error message when decoding illegal message
properties key is unhelpful
Key: PROTON-2236
URL: https://issues.apache.org/jira/browse/PROTON-2236
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Reporter: Kim van der Riet
While decoding a message containing a non-string key (eg a symbol key), then
the following message is seen:
{{Error on transform: Expected String type but found encoding: -93}}
which is not very intuitive. Perhaps converting the type to hex and providing a
stringified version would be better, such as:
{{Expected String type but found encoding 0xb3 (symbol)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071952#comment-17071952 ] Kim van der Riet commented on QPID-8430: The above change prevents non-persistent AMQP 0-10 messages with a trace attached from undergoing a deep copy needed for persistence when the trace is cleared as a part of rerouting. This has a big impact on the memory consumed when these messages are repeatedly rerouted within the same broker. See [https://bugzilla.redhat.com/show_bug.cgi?id=1804134#c25] for a detailed profile of memory used for AMQP 0-10 and AMQP 1.0 messages with and without traces before and after this fix. > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reopened QPID-8430: If a message contains a non-empty-string trace (key "x-qpid.trace"), this fix does not prevent each reroute from re-copying the message as a part of rerouting, and thus for the memory to grow as before the patch. Each reroute is supposed to set the value of this key to the empty string, and subsequent reroutes should not need to recopy the message. However, testing has shown that the test for the presence of the key and its value (using *Message.getPropertyAsString()*) always returns the value of the original message trace annotation, and is thus allowing the trace annotation to be unset over and over, each time with a message deep copy for each reroute. > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPID-8430. Resolution: Fixed > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
Kim van der Riet created QPID-8430: -- Summary: [qpid-cpp] Excessive memory use when rerouting messages Key: QPID-8430 URL: https://issues.apache.org/jira/browse/QPID-8430 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Kim van der Riet Assignee: Kim van der Riet When a message is rerouted several times, the broker's used memory increases rapidly. This is counter-intuitive, considering that the messages themselves are only passing from one queue to another. There is no evidence of a leak, however, only a large growth in consumed memory. An investigation has shown that the process of clearing traces from the message when rerouting (whether they exist or not) causes the message and its frames to be copied (for reasons of avoiding locks on the message, which can affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPID-8425.
Resolution: Fixed
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-
[jira] [Commented] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063385#comment-17063385
]
Kim van der Riet commented on QPID-8425:
Fix commit on master:
[https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=79234737332c4605e2b5bd1e8e31ead45f81deca]
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
>
[jira] [Assigned] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet reassigned QPID-8425:
--
Assignee: Kim van der Riet
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-
[jira] [Created] (QPID-8425) [qpid-cpp] Channel leak on federation links
Kim van der Riet created QPID-8425:
--
Summary: [qpid-cpp] Channel leak on federation links
Key: QPID-8425
URL: https://issues.apache.org/jira/browse/QPID-8425
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Reporter: Kim van der Riet
Attachments: BZ1748054.patch, channel_test.sh
If a broker is repeatedly killed and restarted when it is federated to another
broker, the second broker will run out of channels with a "channel pool is
empty" message. The channel being used for the federation link is not being
returned to the channel pool, and eventually (after ~32k restarts), the channel
pool becomes exhausted.
A reproducer is contained in the attached file "channel_test.sh". If a small
change is made to the Link.cpp constructor which shrinks the channel pool to 5
(see the diff below), then this test will show the error without having to wait
hours for ~32k restarts. The test does 10 restarts.
{noformat}
diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
index 14737e730..790c8ac5e 100644
--- a/src/qpid/broker/Link.cpp
+++ b/src/qpid/broker/Link.cpp
@@ -149,7 +149,7 @@ Link::Link(const string& _name,
currentInterval(1),
reconnectNext(0), // Index of next address for reconnecting in url.
nextFreeChannel(1),
- freeChannels(1, framing::CHANNEL_MAX),
+ freeChannels(1, 6),
connection(0),
agent(0),
listener(l),
{noformat}
Running the test with the above temporary patch, the following is observed:
{noformat}
Channel allocations from broker 6001:
3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 2
3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
...
(repeated several times more)
{noformat}
A fix which returns the channels on links that are closing to the channel pool
is suggested in attached patch BZ1748054.patch. With this patch applied
(together with the temporary pool-shrink patch above), the following is now
observed:
{noformat}
Channel allocations from broker 6001:
2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 2
2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:38 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
{noformat}
Channel 2 is used by a bridge which remains open
(qpid.bridge_session_amq.fanout). The channels are re-used in a cyclical
pattern, which I think is the intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-140) [QIT] Build and run failure on Fedora 31
[
https://issues.apache.org/jira/browse/QPIDIT-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPIDIT-140.
-
Resolution: Fixed
> [QIT] Build and run failure on Fedora 31
>
>
> Key: QPIDIT-140
> URL: https://issues.apache.org/jira/browse/QPIDIT-140
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
> Reporter: Kim van der Riet
> Assignee: Kim van der Riet
>Priority: Major
>
> Fedora 31 has changed the default {{python}} link to point to python 3.x
> rather than python 2.x which the previous versions of Fedroa had used. This
> has caused both the build, install and running of the Python 2 shims to fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-140) [QIT] Build and run failure on Fedora 31
Kim van der Riet created QPIDIT-140:
---
Summary: [QIT] Build and run failure on Fedora 31
Key: QPIDIT-140
URL: https://issues.apache.org/jira/browse/QPIDIT-140
Project: Apache QPID Interoperability Test Suite
Issue Type: Bug
Components: Installation
Reporter: Kim van der Riet
Assignee: Kim van der Riet
Fedora 31 has changed the default {{python}} link to point to python 3.x
rather than python 2.x which the previous versions of Fedroa had used. This has
caused both the build, install and running of the Python 2 shims to fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-139) Update QIT to use Python 3 rather than Python 2
[ https://issues.apache.org/jira/browse/QPIDIT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-139: Component/s: Installation > Update QIT to use Python 3 rather than Python 2 > --- > > Key: QPIDIT-139 > URL: https://issues.apache.org/jira/browse/QPIDIT-139 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Complex Types Test, AMQP Large Content Test, AMQP > Types Test, Installation, JMS Headers and Properties Test, JMS Message Test > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Upgrade the tests to use Python 3 rather than Python 2. The shims will still > run both. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-139) Update QIT to use Python 3 rather than Python 2
Kim van der Riet created QPIDIT-139: --- Summary: Update QIT to use Python 3 rather than Python 2 Key: QPIDIT-139 URL: https://issues.apache.org/jira/browse/QPIDIT-139 Project: Apache QPID Interoperability Test Suite Issue Type: Task Components: AMQP Complex Types Test, AMQP Large Content Test, AMQP Types Test, JMS Headers and Properties Test, JMS Message Test Reporter: Kim van der Riet Assignee: Kim van der Riet Upgrade the tests to use Python 3 rather than Python 2. The shims will still run both. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-138) Change Amqp.netlite shims to run on dotnet
[ https://issues.apache.org/jira/browse/QPIDIT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-138. - Resolution: Fixed > Change Amqp.netlite shims to run on dotnet > -- > > Key: QPIDIT-138 > URL: https://issues.apache.org/jira/browse/QPIDIT-138 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Currently, amqp.netlite shims are compiled and run with mono. Change to using > dotnet core v.2.1 (and possibly v.3.1). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDIT-138) Change Amqp.netlite shims to run on dotnet
[ https://issues.apache.org/jira/browse/QPIDIT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned QPIDIT-138: --- Assignee: Kim van der Riet > Change Amqp.netlite shims to run on dotnet > -- > > Key: QPIDIT-138 > URL: https://issues.apache.org/jira/browse/QPIDIT-138 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Currently, amqp.netlite shims are compiled and run with mono. Change to using > dotnet core v.2.1 (and possibly v.3.1). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-138) Change Amqp.netlite shims to run on dotnet
Kim van der Riet created QPIDIT-138: --- Summary: Change Amqp.netlite shims to run on dotnet Key: QPIDIT-138 URL: https://issues.apache.org/jira/browse/QPIDIT-138 Project: Apache QPID Interoperability Test Suite Issue Type: Task Reporter: Kim van der Riet Currently, amqp.netlite shims are compiled and run with mono. Change to using dotnet core v.2.1 (and possibly v.3.1). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2164) [Python API docs] Remove dependencies on automodapi, replace autosummary tables with static tables
Kim van der Riet created PROTON-2164:
Summary: [Python API docs] Remove dependencies on automodapi,
replace autosummary tables with static tables
Key: PROTON-2164
URL: https://issues.apache.org/jira/browse/PROTON-2164
Project: Qpid Proton
Issue Type: Task
Reporter: Kim van der Riet
Because {{automodapi}} is not packaged in many distributions and relies on
{{pip}} for installation, its presence presents packaging difficulties. Because
the use of {{automodapi}} is limited to the generation of {{autosummary}}
tables, and because these can be easily replaced with static tables, it would
make sense to remove this dependency. It would make the generation of the docs
simpler and remove one step in the process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2157) [Python API Docs] Error creating Sphinx docs on Fedora 29
[
https://issues.apache.org/jira/browse/PROTON-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved PROTON-2157.
--
Resolution: Fixed
> [Python API Docs] Error creating Sphinx docs on Fedora 29
> -
>
> Key: PROTON-2157
> URL: https://issues.apache.org/jira/browse/PROTON-2157
> Project: Qpid Proton
> Issue Type: Bug
> Reporter: Kim van der Riet
>Priority: Major
>
> When building the docs using Shinx on Fedora 29 (Sphinx v.1.7.6), the use of
> math formulas in parts of the documentation cause the following error
> multiple times:
> {noformat}
> WARNING: using "math" markup without a Sphinx math extension active
> {noformat}
> This is not seen on Fedora 30 (Sphinx v.1.8.5), nor CentOS 7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2157) [Python API Docs] Error creating Sphinx docs on Fedora 29
[
https://issues.apache.org/jira/browse/PROTON-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1699#comment-1699
]
Kim van der Riet commented on PROTON-2157:
--
Adding the string {{"sphinx.ext.mathjax"}} to the list of extensions in the
{{python/docs/conf.py}} file solves this issue on F29, and is ignored by builds
on CentOS 7 and F30.
> [Python API Docs] Error creating Sphinx docs on Fedora 29
> -
>
> Key: PROTON-2157
> URL: https://issues.apache.org/jira/browse/PROTON-2157
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Major
>
> When building the docs using Shinx on Fedora 29 (Sphinx v.1.7.6), the use of
> math formulas in parts of the documentation cause the following error
> multiple times:
> {noformat}
> WARNING: using "math" markup without a Sphinx math extension active
> {noformat}
> This is not seen on Fedora 30 (Sphinx v.1.8.5), nor CentOS 7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2157) [Python API Docs] Error creating Sphinx docs on Fedora 29
Kim van der Riet created PROTON-2157:
Summary: [Python API Docs] Error creating Sphinx docs on Fedora 29
Key: PROTON-2157
URL: https://issues.apache.org/jira/browse/PROTON-2157
Project: Qpid Proton
Issue Type: Bug
Reporter: Kim van der Riet
When building the docs using Shinx on Fedora 29 (Sphinx v.1.7.6), the use of
math formulas in parts of the documentation cause the following error multiple
times:
{noformat}
WARNING: using "math" markup without a Sphinx math extension active
{noformat}
This is not seen on Fedora 30 (Sphinx v.1.8.5), nor CentOS 7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved PROTON-2086. -- Resolution: Fixed > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2120) [Proton-c] Threaderciser test does not link
[
https://issues.apache.org/jira/browse/PROTON-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved PROTON-2120.
--
Resolution: Fixed
In the c/test/CMakeLists.txt file:
Using the add_c_test() macro to add the threadersicer test is causing the link
issue. This test defines its own main() function, whereas other tests are part
of a test framework in which the framework provides the main() function.
By explicitly adding the test without the test framework library bits rather
than using the macro solves the issue and the test runs and passes.
> [Proton-c] Threaderciser test does not link
> ---
>
> Key: PROTON-2120
> URL: https://issues.apache.org/jira/browse/PROTON-2120
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Reporter: Kim van der Riet
>Priority: Major
>
> Proton C has a "threaderciser" test which is by default is not enabled.
> However, if it is enabled before compile through the following cmake option:
> {{-DTHREADERCISER="ON"}}
> then the compile fails with a link error:
> {{multiple definitions of 'main'}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2120) [Proton-c] Threaderciser test does not link
[
https://issues.apache.org/jira/browse/PROTON-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-2120:
-
Summary: [Proton-c] Threaderciser test does not link (was:
[Proton-c]Threaderciser test does not link)
> [Proton-c] Threaderciser test does not link
> ---
>
> Key: PROTON-2120
> URL: https://issues.apache.org/jira/browse/PROTON-2120
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Reporter: Kim van der Riet
>Priority: Major
>
> Proton C has a "threaderciser" test which is by default is not enabled.
> However, if it is enabled before compile through the following cmake option:
> {{-DTHREADERCISER="ON"}}
> then the compile fails with a link error:
> {{multiple definitions of 'main'}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2120) [Proton-c]Threaderciser test does not link
Kim van der Riet created PROTON-2120:
Summary: [Proton-c]Threaderciser test does not link
Key: PROTON-2120
URL: https://issues.apache.org/jira/browse/PROTON-2120
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Kim van der Riet
Proton C has a "threaderciser" test which is by default is not enabled.
However, if it is enabled before compile through the following cmake option:
{{-DTHREADERCISER="ON"}}
then the compile fails with a link error:
{{multiple definitions of 'main'}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2119) [Python] Change API to better handle strings where symbols are required
[ https://issues.apache.org/jira/browse/PROTON-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved PROTON-2119. -- Resolution: Fixed Pull request closed. > [Python] Change API to better handle strings where symbols are required > --- > > Key: PROTON-2119 > URL: https://issues.apache.org/jira/browse/PROTON-2119 > Project: Qpid Proton > Issue Type: Task > Components: python-binding > Reporter: Kim van der Riet >Priority: Major > > There are places in the Python API where the AMQP 1.0 specification requires > symbols, but the API accepts strings (and in come cases any type). Change the > API to better handle cases where strings are accepted so as to silently > "upgrade" them to symbols. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2119) [Python] Change API to better handle strings where symbols are required
[ https://issues.apache.org/jira/browse/PROTON-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951360#comment-16951360 ] Kim van der Riet commented on PROTON-2119: -- [Pull request at: https://github.com/apache/qpid-proton/pull/192|https://github.com/apache/qpid-proton/pull/192] > [Python] Change API to better handle strings where symbols are required > --- > > Key: PROTON-2119 > URL: https://issues.apache.org/jira/browse/PROTON-2119 > Project: Qpid Proton > Issue Type: Task > Components: python-binding > Reporter: Kim van der Riet >Priority: Major > > There are places in the Python API where the AMQP 1.0 specification requires > symbols, but the API accepts strings (and in come cases any type). Change the > API to better handle cases where strings are accepted so as to silently > "upgrade" them to symbols. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2119) [Python] Change API to better handle strings where symbols are required
Kim van der Riet created PROTON-2119: Summary: [Python] Change API to better handle strings where symbols are required Key: PROTON-2119 URL: https://issues.apache.org/jira/browse/PROTON-2119 Project: Qpid Proton Issue Type: Task Components: python-binding Reporter: Kim van der Riet There are places in the Python API where the AMQP 1.0 specification requires symbols, but the API accepts strings (and in come cases any type). Change the API to better handle cases where strings are accepted so as to silently "upgrade" them to symbols. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-137) Change broker properties connection to use retries
[ https://issues.apache.org/jira/browse/QPIDIT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-137. - Resolution: Fixed The get_broker_properties() method now allows 25 retry attempts before failing. > Change broker properties connection to use retries > -- > > Key: QPIDIT-137 > URL: https://issues.apache.org/jira/browse/QPIDIT-137 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Currently, if the attempt to obtain broker properties fails because a broker > is not running, the test terminates with an exception. > However, in an automated or CI environment (such as Jenkins) where it is > possible that a broker may take a little longer to start sometimes than > others, it is desirable to have a "window" in which to connect before > failing. Utilizing the retry mechanism to allow a fixed number of retries > before failing will provide this behavior. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDIT-137) Change broker properties connection to use retries
[ https://issues.apache.org/jira/browse/QPIDIT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned QPIDIT-137: --- Assignee: Kim van der Riet > Change broker properties connection to use retries > -- > > Key: QPIDIT-137 > URL: https://issues.apache.org/jira/browse/QPIDIT-137 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet > Assignee: Kim van der Riet >Priority: Major > > Currently, if the attempt to obtain broker properties fails because a broker > is not running, the test terminates with an exception. > However, in an automated or CI environment (such as Jenkins) where it is > possible that a broker may take a little longer to start sometimes than > others, it is desirable to have a "window" in which to connect before > failing. Utilizing the retry mechanism to allow a fixed number of retries > before failing will provide this behavior. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-137) Change broker properties connection to use retries
[ https://issues.apache.org/jira/browse/QPIDIT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-137: Summary: Change broker properties connection to use retries (was: Change connection to obtain broker properties to use retries) > Change broker properties connection to use retries > -- > > Key: QPIDIT-137 > URL: https://issues.apache.org/jira/browse/QPIDIT-137 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Reporter: Kim van der Riet >Priority: Major > > Currently, if the attempt to obtain broker properties fails because a broker > is not running, the test terminates with an exception. > However, in an automated or CI environment (such as Jenkins) where it is > possible that a broker may take a little longer to start sometimes than > others, it is desirable to have a "window" in which to connect before > failing. Utilizing the retry mechanism to allow a fixed number of retries > before failing will provide this behavior. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-137) Change connection to obtain broker properties to use retries
Kim van der Riet created QPIDIT-137: --- Summary: Change connection to obtain broker properties to use retries Key: QPIDIT-137 URL: https://issues.apache.org/jira/browse/QPIDIT-137 Project: Apache QPID Interoperability Test Suite Issue Type: Task Reporter: Kim van der Riet Currently, if the attempt to obtain broker properties fails because a broker is not running, the test terminates with an exception. However, in an automated or CI environment (such as Jenkins) where it is possible that a broker may take a little longer to start sometimes than others, it is desirable to have a "window" in which to connect before failing. Utilizing the retry mechanism to allow a fixed number of retries before failing will provide this behavior. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
