[RESULT][VOTE] enroll Proton and Dispatch in Packit-as-a-Service CI offering from Fedora

[Jiri Daněk]

There were 5 binding +1 votes, and no other votes received. The vote has
passed.

I will inform ASF infra that work on
https://issues.apache.org/jira/browse/INFRA-25349 can proceed.

Thanks,

Re: [VOTE] enroll Proton and Dispatch in Packit-as-a-Service CI offering from Fedora

[Jiri Daněk]

+1

On Fri, Jan 12, 2024, 17:11 Jiri Daněk  wrote:

> I'd like to enable Packit-as-a-Service (
> https://github.com/marketplace/packit-as-a-service) for Qpid Proton and
> Qpid Dispatch GitHub repositories, so that every new PR gets tested on
> Fedora infrastructure (latest released Fedora and Fedora Rawhide).
>
> There are three (gradually more involved) ways to use Packit:
>
> 1. use it as a CI system that runs on Fedora (configurable version and
> system architecture (x86_64, aarch64). The job steps are incidentally
> written in a RPM spec file, but we don't use the produced RPM
> 2. write the spec in a way that it builds useful RPM, but don't publish
> the rpm and don't synchronize the spec file with the spec file that Fedora
> uses in its Proton build
> 3. keep the RPM specs in sync with fedora, when new Proton is released,
> use a single packit command to propose spec changes and version upgrade
> from the upstream proton spec to Fedora Rawhide
>
> My intention is to get Proton all the way to the third scenario.
>
> There are three steps to do this:
>
> First, if the plan is approved in a vote here, ASF infra will enable the
> GitHub integration, https://issues.apache.org/jira/browse/INFRA-25349
> (authed link)
>
> Then, a RPM spec file needs to be written and committed to the repository.
> I volunteer to do that. The Packit CI job will be building from this spec
> file. I'd like to place the spec in a packaging/ sub directory, so that
> files for other packaging systems can be added later and it does not
> clutter the /.
>
> Finally, the spec file should be brought into 1:1 correspondence with the
> spec file that Fedora itself uses. This way, changes to Fedora's spec can
> be proposed and tested in the ASF project first and then shipped into
> Fedora (Rawhide).
>
> Benefits:
>
> * Compilation of Fedora will be tested directly in the GitHub repo and
> issues can be fixed right away.
> * Packit infrastructure offers arm64 machines, so we can opt into
> compiling on arm as well
>
> Supplementary information:
>
> * Packit website: https://packit.dev/
> * Packit guide (GitHub integration): https://packit.dev/docs/guide
> * Packit-as-a-Service: https://github.com/marketplace/packit-as-a-service
> * Fedora wiki page: https://fedoraproject.org/wiki/Packit
>
> Thank you,
> --
> Mit freundlichen Grüßen / Kind regards
> Jiri Daněk
>

[VOTE] enroll Proton and Dispatch in Packit-as-a-Service CI offering from Fedora

[Jiri Daněk]

I'd like to enable Packit-as-a-Service (
https://github.com/marketplace/packit-as-a-service) for Qpid Proton and
Qpid Dispatch GitHub repositories, so that every new PR gets tested on
Fedora infrastructure (latest released Fedora and Fedora Rawhide).

There are three (gradually more involved) ways to use Packit:

1. use it as a CI system that runs on Fedora (configurable version and
system architecture (x86_64, aarch64). The job steps are incidentally
written in a RPM spec file, but we don't use the produced RPM
2. write the spec in a way that it builds useful RPM, but don't publish the
rpm and don't synchronize the spec file with the spec file that Fedora uses
in its Proton build
3. keep the RPM specs in sync with fedora, when new Proton is released, use
a single packit command to propose spec changes and version upgrade from
the upstream proton spec to Fedora Rawhide

My intention is to get Proton all the way to the third scenario.

There are three steps to do this:

First, if the plan is approved in a vote here, ASF infra will enable the
GitHub integration, https://issues.apache.org/jira/browse/INFRA-25349
(authed link)

Then, a RPM spec file needs to be written and committed to the repository.
I volunteer to do that. The Packit CI job will be building from this spec
file. I'd like to place the spec in a packaging/ sub directory, so that
files for other packaging systems can be added later and it does not
clutter the /.

Finally, the spec file should be brought into 1:1 correspondence with the
spec file that Fedora itself uses. This way, changes to Fedora's spec can
be proposed and tested in the ASF project first and then shipped into
Fedora (Rawhide).

Benefits:

* Compilation of Fedora will be tested directly in the GitHub repo and
issues can be fixed right away.
* Packit infrastructure offers arm64 machines, so we can opt into compiling
on arm as well

Supplementary information:

* Packit website: https://packit.dev/
* Packit guide (GitHub integration): https://packit.dev/docs/guide
* Packit-as-a-Service: https://github.com/marketplace/packit-as-a-service
* Fedora wiki page: https://fedoraproject.org/wiki/Packit

Thank you,
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid protonj2 1.0.0-M19 (RC1)

[Jiri Daněk]

+1

* Used the staged maven repo to build
https://github.com/rh-messaging/cli-java/tree/main/cli-protonj2 and run its
self-tests on adopt-openj9 11
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: install python-qpid-proton-0.39.0.tar.gz on linux RHEL8

[Jiri Daněk]

roton-0.39.0.tar.gz from build
> tracker '/tmp/pip-req-tracker-mpq3ibgo'
> Removed build tracker '/tmp/pip-req-tracker-mpq3ibgo'
> ERROR: Command errored out with exit status 1: /usr/bin/python3
> /usr/lib/python3.8/site-packages/pip install --ignore-installed --no-user
> --prefix /tmp/pip-build-env-joipssag/overlay --no-warn-script-location -v
> --no-binary :none: --only-binary :none: --no-index -- setuptools
> 'cffi>=1.0.0' Check the logs for full command output.
> Exception information:
> Traceback (most recent call last):
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/cli/base_command.py", line
> 153, in _main
> status = self.run(options, args)
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/commands/install.py", line
> 401, in run
> resolver.resolve(requirement_set)
>   File "/usr/lib/python3.8/site-packages/pip/_internal/legacy_resolve.py",
> line 202, in resolve
> self._resolve_one(requirement_set, req)
>   File "/usr/lib/python3.8/site-packages/pip/_internal/legacy_resolve.py",
> line 368, in _resolve_one
> abstract_dist = self._get_abstract_dist_for(req_to_install)
>   File "/usr/lib/python3.8/site-packages/pip/_internal/legacy_resolve.py",
> line 315, in _get_abstract_dist_for
> abstract_dist = self.preparer.prepare_linked_requirement(
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/operations/prepare.py",
> line 223, in prepare_linked_requirement
> abstract_dist = _get_prepared_distribution(
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/operations/prepare.py",
> line 49, in _get_prepared_distribution
> abstract_dist.prepare_distribution_metadata(finder, build_isolation)
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/distributions/source/legacy.py",
> line 37, in prepare_distribution_metadata
> self._setup_isolation(finder)
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/distributions/source/legacy.py",
> line 61, in _setup_isolation
> self.req.build_env.install_requirements(
>   File "/usr/lib/python3.8/site-packages/pip/_internal/build_env.py", line
> 201, in install_requirements
> call_subprocess(args, spinner=spinner)
>   File
> "/usr/lib/python3.8/site-packages/pip/_internal/utils/subprocess.py", line
> 242, in call_subprocess
> raise InstallationError(exc_msg)
> pip._internal.exceptions.InstallationError: Command errored out with exit
> status 1: /usr/bin/python3 /usr/lib/python3.8/site-packages/pip install
> --ignore-installed --no-user --prefix /tmp/pip-build-env-joipssag/overlay
> --no-warn-script-location -v --no-binary :none: --only-binary :none:
> --no-index -- setuptools 'cffi>=1.0.0' Check the logs for full command
> output.
>


-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: POSIX threads

[Jiri Daněk]

On Thu, Jun 29, 2023 at 12:46 PM Tiaan Wessels 
wrote:

> Hi,
> The examples for multi-threading focuses on stdc++ threads. I am trying
> instead on integrating qpid proton into a broker application which is based
> on POSIX threads. I am struggling with this e.g. callbacks not called when
> i expect the to be etc. and i am wondering whether this is not due some
> fundamental clash with POSIX threads. Are there any reason why qpid proton
> cannot be integrated into such an environment ?
>

There shouldn't be. C++11 library that you are using is most likely using
pthreads itself.


> I might add that the broker blocks all unix signals on startup and then
> starts a thread dedicated to signal handling. I presume qpid proton does
> not care how signal handling is done ?
>

True, there is no signal handling in Proton whatsoever.


> The container.run is performed from a POSIX thread created for the
> container.
> The main interaction constraint i have is that messages to send appears in
> a POSIX thread within the broker framework and i am transferring this
> message to qpid proton's thread by means of a work queue.
>

Are you using the proton work_queue to communicate between threads?
https://github.com/apache/qpid-proton/blob/f1b9ee0fc69d0836053f1f2c03a72861f787990a/cpp/include/proton/work_queue.hpp#L311-L326
You can only call proton functions from within an event handler, with
carefully specified exceptions. Search the headers for `**Thread safety**`
and `thread safe`.

You could possibly try to compile and run your app with thread sanitizer
(in gcc or clang it is -fsanitize=tsan, for both compilation and linking).
If your only tsan violations are (possibly) in your use of proton, then
this might highlight something, maybe.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid JMS 1.10.0

[Jiri Daněk]

+1

* Added staged maven repo to https://github.com/rh-messaging/cli-java,
upgraded qpid-jms version and ran tests on openjdk 11, which passed
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid JMS 2.4.0

[Jiri Daněk]

+1

* Added staged maven repo to https://github.com/rh-messaging/cli-java,
upgraded qpid-jms version and ran tests on openjdk 11, which passed
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid protonj2 1.0.0-M16

[Jiri Daněk]

+1

* Added staged maven repo to https://github.com/rh-messaging/cli-java,
upgraded protonj2 version and ran tests on openjdk 11, which passed
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Linker error

[Jiri Daněk]

On Thu, 8 Jun 2023 at 08:54, Tiaan Wessels  wrote:
>
> Hi,
> Trying to compile simple_send.cpp for 0.38.0 I get undefined reference to
> proton::connection::reconnected() const
> My link libraries are
> qpid-proton, qpid-proton-core, qpid-proton-cpp and qpid-proton-proactor
> I can't find any other libs to link against. Any ideas?
> Thanks

On Fri, Jun 9, 2023 at 12:46 PM Robbie Gemmell 
wrote:

> C++ isnt my thing, so not sure...though the examples are being
> compiled ok in CI runs and were for 0.38.0. Perhaps give more details
> on your env and commands so someone with more of a clue can try to
> assist you.
>

Try maybe investigating (and/or posting here) the failing
compilation command. If it is not printed and you use make to compile, try

VERBOSE=1 make

That way you can check that you are really linking the libraries you think
you are linking.

Next, when you see qpid-proton-cpp truly is in the list of libraries
linked, you can try checking the symbol is present in the file (command
from
https://stackoverflow.com/questions/34732/how-do-i-list-the-symbols-in-a-so-file/48122967#48122967
)

nm --demangle --dynamic --defined-only --extern-only
path/to/libqpid-proton-cpp.so | grep reconnected

and that should print something like

0002b760 T proton::connection::reconnected() const

(the T after the address means that the symbol is in the text (code)
section and it is global (external)).

Also, perhaps try 0.39.0 in case anything has actually changed.
>

It can't hurt, I guess.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid protonj2 1.0.0-M15

[Jiri Daněk]

On Tue, May 2, 2023 at 7:36 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M15 Qpid ProtonJ2
> release,
> please give it a test out and vote accordingly.
>

+1, I've done the following to check

* configured the staging repository to build
https://github.com/rh-messaging/cli-java on Ubuntu Jammy with OpenJDK 11
* ran cli-java tests with Artemis broker
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Example Schema for qpid-proton connect.json

[Jiri Daněk]

gt;"type": "string",
>"description": "A space separated list of enabled SASL
> mechanisms."
>  }
>}
>  },
>  "tls_properties": {
>"type": "object",
>"required": [ "ca", "cert", "key", "verify" ],
>

from reading the markdown I'd think these are optional too, but I guess
when I already have tls{} then in practice I have to provide all properties


>"ca": {
>  "type": "string"
>},
>"cert": {
>  "type": "string"
>},
>"key": {
>  "type": "string"
>},
>

all these fields can be, according to the markdown doc, also "null", so
doing "type": ["string", "null"] seems appropriate


>"verify": {
>  "type": "boolean"
>}
> }
>   }
> }
>
> ## Appendix -2  file: broken.json
>
> {
> "scheme": "http",
> "host": "example.com",
> "heartbeat": "",
> "user": "foo",
> "password": "bar"
> }


There is a documented requirement that when "scheme" is "amqp", then the
"tls" must not be present. This suggests to me adding

  "$comment": "not-required means forbidden in JSON Schema speak",
  "if": {
"properties": {
  "scheme": {
"const": "amqp"
  }
}
  },
  "then": {
"not": {
  "required": [
"tls"
  ]
}
  }

This way we will at least use some schema-7 features.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [EXTERNAL]Re: Installing qpid-cpp on RHEL9 with python3 fails

[Jiri Daněk]

mmand/easy_install.py", line
> 890, in install_eggs
> return self.build_and_install(setup_script, setup_base)
>   File
> "/usr/lib/python3.9/site-packages/setuptools/command/easy_install.py", line
> 1162, in build_and_install
> self.run_setup(setup_script, setup_base, args)
>   File
> "/usr/lib/python3.9/site-packages/setuptools/command/easy_install.py", line
> 1146, in run_setup
> run_setup(setup_script, args)
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 257,
> in run_setup
> raise
>   File "/usr/lib64/python3.9/contextlib.py", line 137, in __exit__
> self.gen.throw(typ, value, traceback)
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 193,
> in setup_context
> yield
>   File "/usr/lib64/python3.9/contextlib.py", line 137, in __exit__
> self.gen.throw(typ, value, traceback)
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 164,
> in save_modules
> saved_exc.resume()
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 139,
> in resume
> raise exc.with_traceback(self._tb)
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 152,
> in save_modules
> yield saved
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 193,
> in setup_context
> yield
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 254,
> in run_setup
> _execfile(setup_script, ns)
>   File "/usr/lib/python3.9/site-packages/setuptools/sandbox.py", line 42,
> in _execfile
> code = compile(script, filename, 'exec')
>   File "/tmp/easy_install-svgwqopo/qpid-python-1.36.0-1/setup.py", line 42
> raise DistutilsFileError, \
> ^
> SyntaxError: invalid syntax
>

Yeah, this, it is unexpected that `make install` proceeds after this has
happened.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [EXTERNAL]Re: Installing qpid-cpp on RHEL9 with python3 fails

[Jiri Daněk]

I created a Dockerfile/Containerfile that compiles qpid-cpp on CentOS 9.
I'm linking to it below, after a few more progress updates. Try it out (at
https://github.com/apache/qpid-cpp/pull/40) if you want.

On Fri, Apr 14, 2023 at 10:51 PM Do, Eling  wrote:

> Hi Jiri,
>
> Thank you very much for the suggestions.  I will discuss these different
> options with our development team.  I'm not sure that there are specific
> qpid features that we are attached to but more concerned about the
> effort/time needed to make any significant changes.
>

It turned out that getting the basic build to work on RHEL 9 was not that
hard. It required only minimal changes on the qpid-cpp side [1] and
relatively modest changes on the qpid-python [2] side after all

[1] https://issues.apache.org/jira/browse/QPID-8635
[2] https://issues.apache.org/jira/browse/QPID-8631 (up to commit
6d96be6 QPID-8631: make package version string in setup.py compliant with
PEP-440)

As you can see in the CI, the current main of qpid-cpp is running through
the install and only fails on running the tests [3]. In the job, the
current main of qpid-python is installed before trying to install qpid-cpp.
To do this, the GitHub workflow does, in essence

```
git clone https://github.com/apache/qpid-python.git
cd qpid-python
python3 setup.py install --user
```

which is what I am putting into the Containerfile.

[3]
https://github.com/apache/qpid-cpp/actions/runs/4699600134/jobs/8341756181?pr=39#step:18:1283

Here is a GitHub pull request that adds a Dockerfile/Containerfile based on
CentOS 9 that builds qpid-cpp, similarly to how the build from Irina (
https://github.com/irinabov/docker-qpid-cpp-broker) worked.

Please try it out, whether what is built there seems sufficient for your
use: https://github.com/apache/qpid-cpp/pull/40

docker build -f Containerfile -t jdanekrh/jd_qpid-cpp .
docker run --name qpidd --rm -it -p 5672:5672 jdanekrh/jd_qpid-cpp

Regarding what's missing, and the issues I am aware of:
1) bindings (perl, python, ruby client) don't work. the binding code
requires swig3 but rhel9 only has swig4, leading to runtime crashes due to
incompatibilities when trying to use the bindings
2) qpid-tools (for managing the broker, such as `docker exec qpidd
qpid-stat`) don't work, the broker has to be managed by qpid-tools running
somewhere else, where python2 is available

Does this help you move forward? What is the next issue that you are
hitting?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [EXTERNAL]Re: Installing qpid-cpp on RHEL9 with python3 fails

[Jiri Daněk]

On Thu, Apr 13, 2023 at 2:31 PM Do, Eling  wrote:

> Hi Jiri, thanks for responding to my question...much appreciated.  That
> would be great if changing the order of things during the install would
> allow the library install to complete even if the tests cannot run.


Done now, it is failing merrily on setup.py now.


> Any idea as to when a build/snapshot with this change might be available?
>

I won't promise anything. The setup.py processes the spec xml and generates
the .pcl file, which means it actually runs more of the client code than
what I originally expected. I already have all of it fixed on my machine,
passing all the tests, but I am still reviewing it and trying to make as
little of a mess as possible. Specifically, I am confused regarding where
bytes (b"") or strings (u"") should be accepted, for example as message
bodies, various message fields, and so on; I _can_ of course make the
library convert inputs to bytes, but the question is if it is desirable. My
current feeling is that I should not do this and instead have the tests
pass b"" where necessary...) That makes the changes Python 2-neutral,
because in python2, adding b in front of "string" does nothing.

I want to carry on with this, hopefully ending up running an Apache release
vote when the work is done ;P, but it is hardly my top priority.

I don't want to diminish the significance of what I am trying to do here,
but, to tell the truth, if I were a Qpid user wanting a broker on RHEL9, I
would probably run qpid-cpp in a RHEL8-based docker, having compiled it
against Python 2). Or I'd try to migrate to some other, more actively
developed, broker. Are there some particular features of qpidd that you are
especially attached to, that are hard to get from the alternatives?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [EXTERNAL]Re: Installing qpid-cpp on RHEL9 with python3 fails

[Jiri Daněk]

On Wed, Apr 12, 2023 at 4:20 PM Do, Eling  wrote:

> Thanks for your response Robbie.  It seems as though the error I'm getting
> comes from a released version of qpid-python that is automatically
> downloaded during the install (See below).  Do you know if there is a way
> to have it download a snapshot version that includes the fix for the
> python3 syntax errors or if there is a snapshot of qpid-cpp that would
> download a newer version of qpid-python that supports python3?  Sorry I am
> very new to qpid and github so I'm not very familiar with how to find
> specific snapshots on the site.
>

There is no such snapshot published anywhere. At some point we had a
prerelease version on PyPI for qpid-proton, though
https://pypi.org/project/python-qpid-proton/0.38.0.dev0/ so there is
precedent for doing things like this.

I should probably eventually learn how to get PyPI credentials... It should
be enough to upload them to GitHub and then use this nice workflow to do
PyPI releases
https://github.com/apache/qpid-python/blob/main/.github/workflows/python-publish.yml

Personally I am thinking about adding a CMake build option to qpid-cpp
which would tell it to go fetch qpid-python from a git repository, which I
then want to enable in CI, so that I get test results from the combination
of the two git heads.


>   File "/tmp/easy_install-u03_e80q/qpid-python-1.36.0-1/setup.py", line 42
> raise DistutilsFileError, \
> ^
> SyntaxError: invalid syntax
>

It is not yet completely fixed on qpid-python main. I still have there the
Python 2 `except:` written like

except os.error as (errno, errstr):

which needs to be changed. I guess I should also change the order of CI
steps for qpid-python, to first try to install the library, and only then
to run the tests. The current order means I get Python 3 failure on trying
to run tests, and install is not even attempted. For qpid-cpp install it is
enough if the qpid-python lib installs, it does not have to actually work
on Python 3. And making it work, resolving all the bytes/str issues
correctly, will take time.

I'm going to try what I just suggested next. For this evening I got insead
stuck on debugging disappearing tests after switching to the new module
importer (from __future__ import absolute import) ;(

Btw, regarding the disappearning tests on Python 3. The qpid-proton-python
uses the same bespoke testrunner and thus has the same problem
https://issues.apache.org/jira/browse/QPID-8170?focusedCommentId=17711533&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17711533,
but since the test code there does not have nested modules and weird *
imports, this problem does not actually visibly manifest there.
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid ProtonJ2 1.0.0-M14

[Jiri Daněk]

On Mon, Apr 10, 2023 at 6:05 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M14 Qpid ProtonJ2
> release,
> please give it a test out and vote accordingly.


+1, I've done the following to check

* configured the staging repository to build
https://github.com/rh-messaging/cli-java on Fedora 38 with OpenJDK 11
* run cli-java tests
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Which message was accepted?

[Jiri Daněk]

On Fri, Mar 17, 2023 at 8:45 PM Mendez, Raymond
 wrote:

> Hi,
>
> I'm using the qpid proton python 0.34 client and was curious about the
> on_accepted event handler. Is there a way to know *which* message was
> accepted? Will it always be the message last sent, or can they be accepted
> in a different order than sent? I think I read in the C++ documentation
> that sessions ensure sequential message handling. Perhaps I need to
> leverage those?
>
> To summarize my particular use case, I have an on_message handler that
> will reply to incoming messages and I'd like to accept and settle the
> incoming message (and update a local outbox) only after its corresponding
> reply has been accepted.
>
> Hope my question makes sense and thank you in advance!
>

 Hi, I'll try to put forward the general idea. I can try to put together a
sample program if it proves necessary.

The idea is that when you send the message, you either create your own
(unique) tag, or store the "delivery tag" automatically assigned to that
message by proton, and in your `on_accepted(event)` handler you examine the
`event`, look at the delivery tag in it, and that's how you find to which
message this accept event pertains to.

Specifically, the `send(obj, tag=None)` method on a Sender [1] takes an
optional `tag` parameter which is where you can provide your own delivery
tag.

There is a `delivery_tag()` method on Sender which generates a suitable tag
for you (every call to it increments the number it returns by one) [2]

In your `on_accepted(event)`, the `event` contains a `delivery` [3] which
holds the `tag` value with which the message was sent [4].

The db-send example does this. See lines 76 and 82 in
https://github.com/apache/qpid-proton/blob/34b4d930d9a4beaa7728870e215a43880e3e4d07/python/examples/db_send.py#L70-L88.
The first line sets the tag as a message is sent, and the second checks its
value in the handler.

[1]
https://qpid.apache.org/releases/qpid-proton-0.34.0/proton/python/docs/proton.html#proton.Sender.send
[2]
https://qpid.apache.org/releases/qpid-proton-0.38.0/proton/python/docs/proton.html#proton.Sender.delivery_tag
(it does not have a helpful docstring in 0.34)
[3]
https://qpid.apache.org/releases/qpid-proton-0.34.0/proton/python/docs/proton.html#proton.Event.delivery
[4]
https://qpid.apache.org/releases/qpid-proton-0.34.0/proton/python/docs/proton.html#proton.Delivery.tag
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

How to do peer-to-peer (opening listening socket) with protonj2 and proton-dotnet clients?

[Jiri Daněk]

Hello, I am able to connect a socket to an AMQP server using the above
mentioned two new clients, but I was not able to find if it is possible to
open a listening socket.

Is it possible to write a network server with protonj2 and proton-dotnet?

Also, is it possible to pass an already opened socket? I don't have any
real usecase for this, so I'm just asking, since this seems closely related.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid ProtonJ2 1.0.0-M10

[Jiri Daněk]

On Wed, Oct 26, 2022 at 6:55 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M10 Qpid ProtonJ2
> release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/protonj2/1.0.0-M10-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1248
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12352341
>
> Regards
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>
>  
>staging
> https://repository.apache.org/content/repositories/orgapacheqpid-1248
> 
>  
>
>
> The dependency for the protocol engine or the client itself would then be:
>
>
>  org.apache.qpid
>  protonj2
>  1.0.0-M10
>
>
>  org.apache.qpid
>  protonj2-client
>  1.0.0-M10
>
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
+1

Used the staging repo to build https://github.com/rh-messaging/cli-java
:cli-protonj2 and ran tests against Artemis broker on ubi8 in podman. No
failures; fixes for PROTON-2616 and PROTON-2618 did work for me.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid proton-dotnet 1.0.0-M5

[Jiri Daněk]

On Mon, Oct 24, 2022 at 7:15 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M5 Qpid
> proton-dotnet release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-dotnet/1.0.0-M5-rc1/
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/projects/PROTON/versions/12352342
>
> Regards
>
> --
> Tim Bish
>

+1

1. downloaded sources directory
2. ran ./build.sh podman-test on Fedora 37 beta in the sources directory,
no tests failed
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

[protonj2] How do I force the library to send Detach frame on the wire?

[Jiri Daněk]

#x27;null', durable=NONE,
expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1253727474:0] -> Detach{handle=0, closed=true, error=null}
[1253727474:0] <- Detach{handle=0, closed=true, error=null}
[1253727474:1] -> End{error=null}
[1253727474:1] <- End{error=null}
[1253727474:0] -> Close{error=null}
[1253727474:0] <- Close{error=null}

As a workaround, I figured I can do

if (stringToBool(subscriberUnsubscribeString)) {
receiver.receive(1, TimeUnit.SECOND);  // add this receive
call
receiver.close();
return 0;
}

but that does something different than the Qpid JMS example (it sends flow
and actually would receive messages, if there was any).

When I tried tryReceive instead of receive, the AMQP trace stayed the same
as it was originally, that is, no Begin/Attach/Detach was produced either.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [protonj2] How do I ensure that all send()'t messages have been accepted by the other side?

[Jiri Daněk]

On Thu, Oct 6, 2022, 19:07 Timothy Bish  wrote:

> On 10/6/22 12:19, Jiri Daněk wrote:
> > On Thu, Oct 6, 2022 at 5:19 PM Timothy Bish  wrote:
>

[...]

> Sounds like the right strategy for me (at least, to solve my immediate
> > problem) is
> >
> >  Tracker tracker = sender.send(message);
> >  tracker.awaitSettlement();
> >  while (tracker.remoteState() != DeliveryState.accepted()) {
> >  // TODO: am I supposed to increment `delivery-count` of
> the
> > message if I got rejected before?
> >  //  as per
> >
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected
> >  tracker = sender.send(message);  // resend the message
> >  tracker.awaitSettlement();
> >  }
>

(NB. This is not a busy loop involving the network, because sooner or later
the peer will drain my credit, if it intends to keep blocking me. And
sender.send() blocks upon running out of credit, as was already said
before.)

Anyways, the above forces me to have only one message in flight even though
applications can usually benefit from having multiple messages in flight.

Seems like it should work for your test case, other options are to delay
> resend (possibly with back off) or resend up to some max limit,


I don't see much point in those sophisticated strategies with delays, etc
for resends (as opposed to reconnect). When the remote peer stops accepting
messages, it should be either because there is something wrong with the
messages (and then there is no point in resending the same thing again) or
because the peer is unable to handle any messages right now, and then it
should drain my credit. Plain send attempt (which blocks on having credit)
should then be the most appropriate answer.

(Peer can't simply drain credit for anonymous producers, I guess, so ok,
maybe there is a point in these client-driven retry strategies sometimes.)


> all of
> which will depend on your application and how you decide to handle send
> errors.


One could make the same argument against providing reconnect and reconnect
strategies (exponential delay, maybe with jitter) in an AMQP library.


> > Is there an example? Looking at
> >
> https://github.com/apache/qpid-protonj2/blob/f215929395e44a8a0679befe15f96fd95b634c16/protonj2-client-examples/src/main/java/org/apache/qpid/protonj2/client/examples/Send.java#L47
> ,
> > that waits for the settlement, but it does not check what it is. So, if
> the
> > peer rejects the message, the Send example finishes without reporting any
> > errors. AFAIK none of the examples does actually check the
> > tracker/disposition. One-way ack sounds to be the default that most users
> > will want.
>
> We chose to keep the included samples small and concise as a "production
> ready" example tends to not be production ready based on how your own
> application chooses to respond to errors etc and the samples quickly
> become to complex for a novice user to get started.
>

> To be honest, I am not entirely clear what are the reasonable responses to
> > getting rejected, modified, or released dispositions. So a more
> > production-ready =copypastable example of "I just want to send a message"
> > would be very welcome!
>
> The specification defines the meaning of each state
>
>
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-delivery-state
>
> You application then needs to decide how to best handle / report those
> outcomes.
>

How does a typical messaging user learn what possible dispositions might
their broker (let's use Artemis as an example) issue, and how these map to
different broker features? Looking at that AMQP spec in isolation, I
certainly would not realize there is logic needed to handle full addresses.
Do I really need to read the broker docs from cover to cover? (
https://activemq.apache.org/components/artemis/documentation/latest/flow-control.html,
section Blocking AMQP Producers; moreover, the docs say "Once this upper
bound is reach Artemis will start rejecting AMQP messages." It does not
make any explicit reference to AMQP dispositions, so it can be easily
missed when searching for it).

In the AMQP world, it is even possible to write portable clients, or are
the differences and gotchas between different peers (Artemis, Dispatch
Router (which does not always grant credits to receivers by default...), or
Azure Service Bus) so great that it is necessary to focus on one, and then
there is extensive testing required to catch all those quirks? And every
user of the peer has to discover them for themselves, when building a
client?

On Thu, Oct 6, 2022 at 8:43 PM Connie Yau 
wro

Re: [protonj2] How do I ensure that all send()'t messages have been accepted by the other side?

[Jiri Daněk]

On Thu, Oct 6, 2022 at 5:19 PM Timothy Bish  wrote:

> On 10/6/22 10:36, Jiri Daněk wrote:
> > In my code [1], I create a sender using connection.createSender(), that
> is,
> > I don't use Session at all. The Artemis broker on the other side is
> > configured to BLOCK incoming messages if the queue exceeds a certain
> > configured size. In AMQP terms, the broker sends disposition of Rejected,
> > which looks this way in Wireshark
> >
> > Advanced Message Queueing Protocol
> >  Length: 135
> >  Doff: 2
> >  Type: AMQP (0)
> >  Channel: 0
> >  Performative: disposition (21)
> >  Arguments
> >  Role: receiver
> >  First: 47
> >  Last: 47
> >  Settled: True
> >  Rejected
> >  Error
> >  Condition: amqp:resource-limit-exceeded
> >  Description: Address is full:
> > test_broker_blocks_client_many_messages_in_queue
> >
> > (See zipped capture file at
> >
> https://github.com/rh-messaging/cli-java/issues/455#issuecomment-1270166736
> )
> >
> > However, my program does not respond to this as if the messages were
> > delivered correctly, and sends detach and then close. The rejected
> messages
> > then disappear.
> >
> > Do I need to examine the returned Tracker objects and check what became
> of
> > my messages? Does the library "take responsibility" for the message the
> > moment I call send, so I can assume any necessary buffering and
> redelivery
> > will be taken care of? Is this supposed to work even if there is, say,
> > reconnect/failover between brokers while I am sending?
>
> Send returns the tracker for you to examine and or wait on the
> settlement future so that you can ascertain if the remote has accepted
> or rejected the delivery, the client does not attempt to buffer any
> messages other than the singular case of a send that blocks because
> there is not credit in which case that blocked send will either succeed
> (as in writing it to the wire but still could be rejected) if credit is
> granted or it would fail if the link was closed (connection dropped
> etc).  The trySend method exists to avoid that blocking behavior if your
> application doesn't want to deal with blocking on lack of credit scenario.
>

I guess I've been spoiled by other Qpid clients which do handle some
resends. Although I don't think that any AMQP client automatically handles
reconnects/failovers (so that no messages are lost)

Sounds like the right strategy for me (at least, to solve my immediate
problem) is

Tracker tracker = sender.send(message);
tracker.awaitSettlement();
while (tracker.remoteState() != DeliveryState.accepted()) {
// TODO: am I supposed to increment `delivery-count` of the
message if I got rejected before?
//  as per
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected
tracker = sender.send(message);  // resend the message
tracker.awaitSettlement();
}


> > Is this reject disposition-related behavior a client bug? (After thinking
> > more about it, having written the above, I became convinced it probably
> is.)
>
> Not a bug as far as I can see as it sounds like it is working as
> intended, and there are tests checking for same.
>

Is there an example? Looking at
https://github.com/apache/qpid-protonj2/blob/f215929395e44a8a0679befe15f96fd95b634c16/protonj2-client-examples/src/main/java/org/apache/qpid/protonj2/client/examples/Send.java#L47,
that waits for the settlement, but it does not check what it is. So, if the
peer rejects the message, the Send example finishes without reporting any
errors. AFAIK none of the examples does actually check the
tracker/disposition. One-way ack sounds to be the default that most users
will want.

To be honest, I am not entirely clear what are the reasonable responses to
getting rejected, modified, or released dispositions. So a more
production-ready =copypastable example of "I just want to send a message"
would be very welcome!

Also, what changes when transactions are involved on top of this?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

[protonj2] How do I ensure that all send()'t messages have been accepted by the other side?

[Jiri Daněk]

In my code [1], I create a sender using connection.createSender(), that is,
I don't use Session at all. The Artemis broker on the other side is
configured to BLOCK incoming messages if the queue exceeds a certain
configured size. In AMQP terms, the broker sends disposition of Rejected,
which looks this way in Wireshark

Advanced Message Queueing Protocol
Length: 135
Doff: 2
Type: AMQP (0)
Channel: 0
Performative: disposition (21)
Arguments
Role: receiver
First: 47
Last: 47
Settled: True
Rejected
Error
Condition: amqp:resource-limit-exceeded
Description: Address is full:
test_broker_blocks_client_many_messages_in_queue

(See zipped capture file at
https://github.com/rh-messaging/cli-java/issues/455#issuecomment-1270166736)

However, my program does not respond to this as if the messages were
delivered correctly, and sends detach and then close. The rejected messages
then disappear.

Do I need to examine the returned Tracker objects and check what became of
my messages? Does the library "take responsibility" for the message the
moment I call send, so I can assume any necessary buffering and redelivery
will be taken care of? Is this supposed to work even if there is, say,
reconnect/failover between brokers while I am sending?

When is the "send()'t but not actually sent" buffer of messages emptied?
When I attempt to close the connection? What happens if there are some
outstanding messages that (for some reason) cannot be delivered? Should I
expect some exception in that case? (I assume that to properly handle this,
I have to manage the Tracker objects myself as I am calling send(), and
then maybe store the unsent messages to disk, or preserve them some other
way.)

Is this reject disposition-related behavior a client bug? (After thinking
more about it, having written the above, I became convinced it probably is.)

[1]
https://github.com/rh-messaging/cli-java/blob/6cc43514c0ca7eee0385d227faeb574b451075f3/cli-protonj2/src/main/java/com/redhat/mqe/CliProtonJ2Sender.java#L263
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid ProtonJ2 1.0.0-M9

[Jiri Daněk]

On Tue, Sep 20, 2022 at 8:44 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M9 Qpid ProtonJ2
> release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/protonj2/1.0.0-M9-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1247
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12352228
>
> Regards
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>
>  
>staging
> https://repository.apache.org/content/repositories/orgapacheqpid-1247
> 
>  
>
>
> The dependency for the protocol engine or the client itself would then be:
>
>
>  org.apache.qpid
>  protonj2
>  1.0.0-M9
>
>
>  org.apache.qpid
>  protonj2-client
>  1.0.0-M9
>
>
> --
> Tim Bish
>

+1

- used the staged maven repo to build cli-java [1] and run its tests

[1] https://github.com/rh-messaging/cli-java
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid proton-dotnet 1.0.0-M4

[Jiri Daněk]

On Wed, Sep 21, 2022 at 10:54 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M4 Qpid
> proton-dotnet release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-dotnet/1.0.0-M4-rc1/
>
> The JIRAs assigned are:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12352199
>
> Regards
>
> --
> Tim Bish
>

+1

- checked sha512
- ran ./build.sh podman-test on Fedora 36, nothing failed

-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid protonJ2 1.0.0-M8

[Jiri Daněk]

+1

I checked things over as follows:
- Verified the checksum file.
- Used the staged maven repository to compile
https://github.com/rh-messaging/cli-java/tree/main/cli-protonj2 and run
tests.

On Tue, Aug 23, 2022 at 6:58 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M8 Qpid protonJ2
> release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/protonj2/1.0.0-M8-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1242
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12352040
>
> Regards
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>
>  
>staging
> https://repository.apache.org/content/repositories/orgapacheqpid-1242
> 
>  
>
>
> The dependency for the protocol engine or the client itself would then be:
>
>
>  org.apache.qpid
>  protonj2
>  1.0.0-M8
>
>
>  org.apache.qpid
>  protonj2-client
>  1.0.0-M8
>
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid proton-dotnet 1.0.0-M3

[Jiri Daněk]

On Mon, Aug 8, 2022 at 6:55 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M3 Qpid
> proton-dotnet release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-dotnet/1.0.0-M3-rc1/
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12352093
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
+1

- Verified the signature.
- Ran the source build and tests on Fedora 36 with dotnet 6.0.106 using
"./build.sh test", no tests failed.
- Ran the source build and tests on Centos Stream 8 with
dotnet 6.0.100-rc.2.21503.1 using "./build.sh test", no tests failed.
- Ran the source build and tests in a container using "./build.sh
podman-test", no tests failed.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid proton-dotnet 1.0.0-M1 (RC1)

[Jiri Daněk]

+1, provided that https://issues.apache.org/jira/browse/PROTON-2560 gets
release-noted

* Validated source archive checksum
* Built from source on Fedora 36
* Ran several examples (after applying workaround for PROTON-2560)
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid proton-dotnet 1.0.0-M1 (RC1)

[Jiri Daněk]

On Fri, May 27, 2022 at 6:05 PM Timothy Bish  wrote:

> On 5/27/22 11:42, Robbie Gemmell wrote:
> > On Thu, 26 May 2022 at 19:57, Timothy Bish  wrote:
> >> Hi folks,
> >>
> >> I have put together a release candidate for a 1.0.0-M1 Qpid
> >> proton-dotnet release,
> >> please give it a test out and vote accordingly. This is the first
> >> milestone release for this
> >> new .NET based AMQP client and accompanying protocol engine.
> >>
> >> The source and binary archives can be grabbed from:
> >> https://dist.apache.org/repos/dist/dev/qpid/proton-dotnet/1.0.0-M1-rc1/
> >>
> >> The JIRAs assigned are:
> >> https://issues.apache.org/jira/projects/PROTON/versions/12351750
> >>
> >> Regards
> >>
> >> --
> >> Tim Bish
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >>
> > +1
> >
> > I checked things over as follows:
> > - Verified the signature + checksum files.
> > - Checked for LICENCE + NOTICE files in the archives.
> > - Used "mvn apache-rat:check" to verify headers in the source archive.
> > - Ran the source build and tests in container using "./build.sh
> > podman-test", all passed.
> >
> > Some trivial niggles noticed:
> > - The "podman-test" command isnt listed in the build.sh usage
>
> Thanks, that was a late addition and I'll add an entry for the next
> release.  I noticed some other cleanups that could be done but thought
> it was good to get a release milestone out so more eyes can hit this
>
>
> > - The usage help is effectively printed twice due to the script always
> > setting debug flag.
> > - The GitHub Actions CI build is using .Net 5 and generating a warning
> > about it being EOL, the job should be updated to use .Net 6 instead.
>
> Will move that up to 6 still targeting the  5.0 framework
>

When I wanted to build from source using dotnet 6.0 on Linux, I got an
error saying that 5.0 is required. I think that (if possible), the project
should be configured to use "current or any higher available" version.
Given that dotnet 7.0 is already a thing

```
/home/jdanek/repos/qpid/qpid-proton-dotnet/examples/Example.HelloWorld/bin/Debug/net5.0/Example.HelloWorld
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' (x64) was not found.
  - The following frameworks were found:
  6.0.4 at [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or
SDK.

The specified framework can be found at:
  -
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=fedora.36-x64

Process finished with exit code 150.
```
It should be that roll-forward policy thing, afaik. Meanwhile, I just did
search/replace for net5.0 to net6.0.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid JMS 1.6.0

[Jiri Daněk]

+1

* Validated checksums
* Built from source and ran the test suite on OpenJDK 11
* Ran https://github.com/rh-messaging/cli-java tests using the staged maven
repository artifacts

On Mon, Mar 28, 2022 at 6:15 PM Robbie Gemmell 
wrote:

> Hi folks,
>
> I have put together a spin for a 1.6.0 Qpid JMS client release, please
> give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/1.6.0-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1237
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524&version=12351131
>
> Regards,
> Robbie
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1237
> 
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-jms-client
> 1.6.0
>   
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid Proton 0.37.0 (RC2)

[Jiri Daněk]

On Fri, Mar 18, 2022 at 10:20 AM Roddie Kieley  wrote:

> Has anyone else been testing with python 3.10? I see that we specify
> python 3.6+ as per:
>
> -- Found Python: /usr/bin/python3.10 (found suitable version "3.10.0",
> minimum required is "3.6") found components: Interpreter Development
> Development.Module Development.Embed
>
> but on Fedora 34 with python 3.10 installed and built using gcc I see that
> the c-fdlimits-tests fail intermittently. With clang 12.0.1 + python 3.10
> the list of failures is larger and more consistent. Should we expect this
> to be a python 3.10 to be usable at the moment? If this is not an issue
> specific to my environment, are we able to release note it?
>

Python 3.10 is default on Fedora 35 as well, so I expect most people here
will use this version of Python.

Does the fdlimits failure look anything like the former problems with the
test?
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PROTON%20AND%20text%20~%20c-fdlimits-tests

What are the other failures? Could it be that newer Python is more
sensitive to detecting resource leaks?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid Proton 0.37.0

[Jiri Daněk]

+- "?"

A GitHub PR has been opened, which suggests there might be a refcounting
issue in the Python binding. https://github.com/apache/qpid-proton/pull/360.
Looking at the history of the relevant code, it looks to me that the PR is
trying to fix reference counting in code last updated in PROTON-2430, which
was already released as Proton 0.36.0. Therefore, whatever issue the
contributor is trying to solve, this is not a release-to-release regression.

If they are using only released pypi packages, then I think this is the
earliest they got the code to their hands and can report an issue, though.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid ProtonJ2 1.0.0-M4

[Jiri Daněk]

On Mon, Dec 20, 2021 at 9:11 PM Timothy Bish  wrote:

> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M4 Qpid ProtonJ2
> release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/protonj2/1.0.0-M4-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1236
>
> The JIRAs assigned are:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12350719
>
> Regards
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>
>  
>staging
> https://repository.apache.org/content/repositories/orgapacheqpid-1236
> 
>  
>
>
> The dependency for the protocol engine or the client itself would then be:
>
>
>  org.apache.qpid
>  protonj2
>  1.0.0-M4
>
>
>  org.apache.qpid
>  protonj2-client
>  1.0.0-M4
>
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
+1

* verified checksums
* built successfully from source code with running all tests
* ran successfully "HelloWorld" example against  Apache ActiveMQ Artemis
2.19.0
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Issue building Qpid Proton 0.35 using source code package

[Jiri Daněk]

I had a similar-looking problem, and in my case it was caused by the fact
that my Cyrus SASL was compiled with a different version of OpenSSL than
was the version I tried to use when later compiling Qpid Proton.

You can try running `ldd` against the Cyrus SASL .so files to see what
OpenSsl they want. If this mismatch is the problem, then recompiling and
reinstalling Cyrus SASL should help.

Re: Random "local-idle-timeout expired" disconnections with Qpid Proton C++

[Jiri Daněk]

>
> In particular, I am currently using Qpid Proton 0.33.0 (the C++ version) in


My thought was to try some other versions of Qpid Proton. That is, 0.32.0
(should not be affected by PROTON-2422) and the current mainline (which
should contain fix for https://issues.apache.org/jira/browse/PROTON-2411).
Too bad that the issue cannot be reproduced quickly and reliably; that
would make this sort of debugging approach much more practical.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [Dispatch] what's the purpose of `type_registered` flag in router_node.c

[Jiri Daněk]

Thanks Ted, this really helps! Linking
https://issues.apache.org/jira/browse/DISPATCH-2201 to
track type_registered's removal.

On Fri, Jul 16, 2021 at 3:40 PM Ted Ross  wrote:

> Hi Jiri,
>
> In normal operation of the router, there is only one call to 'qd_router',
> so I'm not sure we really need 'type_registered'.  That code has been there
> from the very beginning so I don't think it was added to fix a particular
> problem.  I think it could safely be removed.
>
> -Ted
>
> On Fri, Jul 16, 2021 at 5:56 AM Jiri Daněk  wrote:
>
> > Hello folks
> >
> > ```
> > static int type_registered = 0;
> >
> > qd_router_t *qd_router(qd_dispatch_t *qd, qd_router_mode_t mode, const
> char
> > *area, const char *id)
> > {
> > if (!type_registered) {
> > type_registered = 1;
> > qd_container_register_node_type(qd, &router_node);
> > }
> > ```
> >
> >
> https://github.com/apache/qpid-dispatch/blob/d8800269d3a80225794be9914b5fc9f8d6118d04/src/router_node.c#L1623-L1630
> >
> > I'd like to understand the motivation behind this code better.
> >
> > Some parts of the codebase assume that there may be many qd_dispatch_t
> > instances around, while others assume there is only one. There is the
> > `dispatch` global variable in python_embedded.c, there is the global flag
> > `type_registered` here, but the `qd_dispatch_t` pointer is usually passed
> > through function argument (as if there could be more than one).
> >
> > Having this check for `type_registered` prevents me from stopping and
> > freeing one instance of a router, then immediately starting another in
> the
> > same process. I want to do this for testing purposes. What happens now is
> > that the second router I start will not function correctly; deleting this
> > type_registered logic makes it work right (as far as my tests so far are
> > concerned).
> >
> > It seems to me that it should be perfectly ok to have multiple dispatch
> > instances in the single process, as long as there is only one at a time.
> > --
> > Mit freundlichen Grüßen / Kind regards
> > Jiri Daněk
> >
>


-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

[Dispatch] what's the purpose of `type_registered` flag in router_node.c

[Jiri Daněk]

Hello folks

```
static int type_registered = 0;

qd_router_t *qd_router(qd_dispatch_t *qd, qd_router_mode_t mode, const char
*area, const char *id)
{
if (!type_registered) {
type_registered = 1;
qd_container_register_node_type(qd, &router_node);
}
```
https://github.com/apache/qpid-dispatch/blob/d8800269d3a80225794be9914b5fc9f8d6118d04/src/router_node.c#L1623-L1630

I'd like to understand the motivation behind this code better.

Some parts of the codebase assume that there may be many qd_dispatch_t
instances around, while others assume there is only one. There is the
`dispatch` global variable in python_embedded.c, there is the global flag
`type_registered` here, but the `qd_dispatch_t` pointer is usually passed
through function argument (as if there could be more than one).

Having this check for `type_registered` prevents me from stopping and
freeing one instance of a router, then immediately starting another in the
same process. I want to do this for testing purposes. What happens now is
that the second router I start will not function correctly; deleting this
type_registered logic makes it work right (as far as my tests so far are
concerned).

It seems to me that it should be perfectly ok to have multiple dispatch
instances in the single process, as long as there is only one at a time.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [Qpid-dispatch] timespec not defined on Windows

[Jiri Daněk]

 into Linux, then I think that would be acceptable.  This
> > would add value to both platforms.
> >
> > >
> > > For now I am working on the other parts of the code which are
> incompatible.
> > >
> > > Another thing which has come up is implicit conversion of int types.
> MSVC
> > > 2013 throws a lot of warnings related to implicit conversions between
> types
> > > (unsigned int, size_t, pointer math). A lot of these errors are
> probably fixed
> > > by changing types to size_t.
> > >
> > > Are there any places in the code where we should watch for the
> > > performance impact of these changes? Specifically some places such as
> > > qd_composite_t use uin32_t explicitly.
> >
> > The explicit uint32_t vales in qd_composite_t are matched to 32-bit
> > length and count fields defined in the AMQP specification.  We should
> > take these instances on one-by-one.  I'd be happy to help with this.  I
> > do have access to the MSVC environment.
> >
> > >
> > > A
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>



-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Proposal for Python type annotations in Qpid Proton and Qpid Dispatch

[Jiri Daněk]

PR: https://github.com/apache/qpid-proton/pull/325

I've focused on simple and mostly obvious declarations there. I want to get
them merged first, and then tackle the ones where e.g. current
documentation does not match the actual types. While working on the PR, I
encountered some less obvious features of Python typing, which I'd like to
briefly mention in the remainder of the email. Chances are that if you are
new to Python typing, you haven't encountered them yet.

# if TYPE_CHECKING

Importing a file just to get type definition sometimes leads to circular
imports. Conditional import like this breaks the cycle for regular
execution; when type-checking, the checkers can deal with the import
cycles, since they are not actually executing the checked code.

# from __future__ import annotations

This is an useful Python language extension, that can be opted into
starting with Python 3.7. When enabled, it stops Python from trying to
evaluate the inline type annotations as it is loading each file. This
allows dropping the single quotes for types that are only defined later in
the file, or are conditionally imported.

# @overload

This allows multiple type signatures for a method. For example, _check_type
does casting in the following way: If an argument of type symbol or str is
given, the function will cast it to a symbol. If allow_ulong is True, then
also ulong return value is possible. If raise_on_error is False, then any
type is accepted and returned. That leads me to a crazy type definition
along the following lines. This is not something that I added to a PR just
yet; I am now focusing on short, sweet and useful types, for now.

_T = TypeVar('_T')

@overload
def _check_type(s: Union[symbol, str], allow_ulong: bool = ...,
raise_on_error: bool = ...) -> symbol:
...


@overload
def _check_type(s: Any, allow_ulong: Literal[False] = ..., raise_on_error:
Literal[True] = ...) -> Union[symbol]:
...


@overload
def _check_type(s: Any, allow_ulong: Literal[True] = ..., raise_on_error:
Literal[True] = ...) -> Union[symbol, ulong]:
...

@overload
def _check_type(s: _T, allow_ulong: bool = ..., raise_on_error:
Literal[False] = ...) -> _T:
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Proposal for Python type annotations in Qpid Proton and Qpid Dispatch

[Jiri Daněk]

Hi Folks!

Having dropped Python 2.7 support in Qpid Proton and Qpid Dispatch recently
(see thread "Some (long awaited?) suggestions to deprecate Python 2 and C++
03 support" from Andrew Stitcher), I propose to introduce Python type
annotations into the codebase.

Optional typing syntax was added in Python 3.5 and Python 3.6. The syntax
is (subjectively speaking) quite ugly (many people think that,
https://lwn.net/Articles/643269/). On the other hand, automatically
typechecked type annotations provide numerous benefits to the users:

  * Up-to-date documentation: oftentimes, type signatures give strong usage
hints when trying to use an API. Am I allowed to pass None here? When the
type annotation says Optional[str], the answer is clear. Can this method
return None?
  * Code completion and linting: There is IDE support as well as standalone
static type checkers for Python type annotations. The IDE uses the
annotation information for code autocompletion. Both the checkers and IDEs
report type mismatches in code.

The best single-source introduction to optional types in Python is probably
the MyPy documentation,
https://mypy.readthedocs.io/en/stable/introduction.html.

One example of AMQP 1.0 client (for JavaScript) that ships typing stubs is
https://github.com/amqp/rhea, contributed in
https://github.com/amqp/rhea/pull/70.

# Inline or stubs?

There are two possibilities for writing type annotations in Python. Either
stubs in separate .pyi files, or inline annotations in function definitions.

The stubs approach allows to keep the ugly typing syntax out of the main
sources. Historically it was the approach used when Python 2.7
compatibility had to be maintained or when the types were being written by
somebody other than the library author. To simplify working with stubs,
PyCharm IDE draws a star gutter icon for module members annotated in a
separate stub file that allows switching back and forth.

I feel that stubs would make some sense for Qpid Proton, and less sense for
Qpid Dispatch. Proton is a library defining a public API, changes to which
happen infrequently. Stubs allow to hide the syntactic ugliness. On the
other hand, inline types are easier to work with as it is not necessary to
switch between files much. From a library user's point of view, the chosen
approach does not matter.

Over all, my preference goes to inline type annotations, simply because
they are easier to write and maintain.

Due to the notorious ugliness of the inline syntax, a reformat of parameter
lists may be needed. As an example, going from

def f(self, a, b=None, c=42):
...

to

def f(
self,
a: Union[A, B, C],
b: Optional[str] = None,
c: int = 42
) -> Dict[str, Any]:
...

See https://github.com/sphinx-doc/sphinx/issues/5868 for one more hairy
example.

# Which checker?

  * https://github.com/python/mypy

  * https://github.com/facebook/pyre-check
  * https://github.com/google/pytype
  * https://github.com/microsoft/pyright

I believe MyPy should be supported at first, and one other checker can be
added later. The checkers all use the same type syntax, but they differ in
how they do type inference and therefore what errors they report on a
particular piece of code. Code which passes MyPy might fail on Pyre, for
example.

https://google.github.io/pytype/faq.html#how-is-pytype-different-from-other-type-checkers

# Initial annotations proposal

I propose to generate initial type annotations by capturing runtime types
using https://github.com/Instagram/MonkeyType, introduce them inline, and
edit out the most egregious artifacts that this method produces (i.e. large
Union types where the algorithm fails to divine the programmer's intention
and does not generalize the type). In a subsequent commit, I propose adding
a MyPy CI job and finetune the types and write more of them so that the
check passes. Finally, I'd like to attempt to make MyPy check pass in
--strict mode.

Having typechecking in place should be helpful for PROTON-2095 Move away
from SWIG to CFFI, in order to exactly preserve the API.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Bad random number seed for link names

[Jiri Daněk]

There are two separate aspects in this, IMO. First, the random seed, and
then second, the pseudorandom algorithm.

The problem to me seems to be the seed. Even Mersenne Twisters will produce
duplicate UUIDs if they get seeded with the same initial seed data.
Therefore, what seems to be needed is to incorporate use
of std::random_device when seeding the UUID generator. Afaik it is a good
idea to also use Mersenne Twister instead of std::rand while making these
changes, but that is just an extra improvement to me.

If I understand correctly, in your application you are now using the
two-parameter version of container::container(messaging_handler& h, const
std::string& id) and you are providing your own id, generated using
std::mt19937_64. Is that correct?

On Wed, Jun 9, 2021 at 8:10 PM Robbie Gemmell 
wrote:

> I have no idea what approach might be taken if any, but this certainly
> seems worth a JIRAt o me to track the general issue at least.
>
> On Wed, 9 Jun 2021 at 14:32, rherbert  wrote:
> >
> > We spent a while tracking down a problem when we start up many services
> in
> > Docker containers simultaneously - when a client sent a request, we would
> > get responses from multiple services, even though each service should
> have
> > been bound to its own exchange.
> >
> > We tracked the problem down to here:
> >
> https://github.com/apache/qpid-proton/blob/8ddf5399013b02f1fd13bda3fee7886bd48a98be/cpp/src/uuid.cpp#L45
> >
> > When you're starting services in Docker containers, they all get the same
> > PID - so if you're starting a bunch of Docker containers simultaneously,
> the
> > odds are good that the seed will be the same across several of the
> services.
> > We were even seeing this problem across multiple hosts when the
> deployment
> > would push out a new build.
> >
> > We've worked around the issue by adding service identifiers and our own
> > unique identifier using std::mt19937_64.  I imagine our multi-container
> > situation is the only use case where this error would be common, but
> with a
> > lot of users, I would think that there would be intermittent issues.
> >
> > Is this something I should open a ticket for?  I don't have a patch for
> > proton - I don't know if using std::mt19937_64 is acceptable for the
> proton
> > code base.
> >
> >
> >
> > --
> > Sent from:
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid ProtonJ2 1.0.0-M1 (RC1)

[Jiri Daněk]

+1

- Checked checksum files
- Used the staged Maven repository to build examples in the unpacked bin
release archive
- Tried the Helloworld, and Send and Receive examples with ActiveMQ Artemis
2.16
- Used a Quiver arrow in p2p mode against qpid-proton-c receiver/listener
to measure throughput

Doing this, I noticed the following

- bin release archive does not have any README files for the examples, so I
had to download and look into the src archive for instructions
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [jira] [Commented] (PROTON-2370) [cpp] An accessor for the delivery tag

[Jiri Daněk]

On Sun, Apr 11, 2021 at 7:33 PM Rakhi Kumari  wrote:

> Hi,
>
> I'm working on PROTON-2370
> <https://issues.apache.org/jira/browse/PROTON-2370> and created the draft
> PR <https://github.com/apache/qpid-proton/pull/309> for the same. While
> working on it I was seeing code snippets similar to "struct pn_session_t;",
> I haven't seen this C++ syntax before. Can you please tell me what it means?
>

Hey, I am not sure what exactly you are asking, so I am going to give a
long-winded answer, sorry. A struct is a carry-over from the C language. So
the answer depends on whether you are compiling your code as C or C++.

In C++ a struct it is like a class where the default access modifier is
public:, unless you declare it otherwise. In a C++ class, all members are
private: by default, unless you declare otherwise.

When you compile as C, a struct can only have data members, no methods.
That's because C is not an object-oriented language, so the C++ syntax to
add methods is not supported. If you want to have objects in C, you can
define functions that take the struct (or pointer to a struct, more like)
as their first argument (for consistency), name the functions in a
consistent way, and only manipulate the struct using these functions; which
is exactly what Proton-c does. You cannot have inheritance in C, though.
Well, actually, you can use a library to add some object support to C, for
example https://en.wikibooks.org/wiki/C_Programming/GObject, but Proton-c
does not use any of that.


>
> https://github.com/apache/qpid-proton/blob/df978869030bb811b5e9cd99f6c390c9ca9bf97c/cpp/src/proton_bits.hpp#L42
>

That on line 42 is a forward declaration of a struct. You can do this
instead of actually including the header file, and then you can use the
type as a reference (pointer). You cannot use it as a value because with
only a forward-declaration, the compiler does not know the size of the
struct. Usually it is better to simply include the header; you may not want
to do that 1) for compile efficiency, if the header file is very big 2) if
the header file is not available, as e.g. in this case in Proton, the
header is called "engine-internal.h"; private headers are one way in C to
achieve encapsulation; here the C++ binding is breaking encapsulation, to
some (small) degree, hopefully for good reasons.


> I'm trying to understand the above in order to fix the build error I'm
> getting on the same PR. In case you already know what's wrong here, can you
> please guide me?
>
>
> https://github.com/apache/qpid-proton/blob/df978869030bb811b5e9cd99f6c390c9ca9bf97c/cpp/include/proton/tag.hpp#L42
>
>
> [image: image.png]
>

Please don't include pictures in e-mails to the mailing list; the mailing
list is afaik striping them, the only reason I see this is that you sent me
a CC in addition 'P Simply copy-paste the text from the terminal. The text
color does not matter.

I'm going to comment on the PR directly, just because I can 'P BTW, thanks
for posting the PR, it helps with debugging. I can simply pull your code in
its entirety and play with it...
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Thu, Apr 8, 2021 at 11:51 AM mehaboob shariff 
wrote:

> Sorry if I am causing too much trouble but everything seems fine from

running the above commands
>

Well, we have to sort out the basics. You cannot do your task if you don't
have a development environment working.


> mrrobot@mrrobot:~/Desktop/qpid-proton/build$ ls
> ../cpp/src/container_test.cpp
> ../cpp/src/container_test.cpp
> mrrobot@mrrobot:~/Desktop/qpid-proton/build$ git status
> On branch main
> Your branch is up to date with 'origin/main'.
>

Did you already try to delete the entire ~/Desktop/qpid-proton, and do the
git checkout, etc. again?

One way to possibly break the build would be to rename the build directory
after you've already run cmake in it... something like this. That's why I
think a clean start should always be tried, at some point.
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Thu, Apr 8, 2021 at 11:11 AM mehaboob shariff 
wrote:

> Scanning dependencies of target container_test
> make[2]: Leaving directory '/home/mrrobot/Desktop/qpid-proton/build'
> make -f cpp/CMakeFiles/container_test.dir/build.make
> cpp/CMakeFiles/container_test.dir/build
> make[2]: Entering directory '/home/mrrobot/Desktop/qpid-proton/build'
> make[2]: *** No rule to make target '../cpp/src/container_test.cpp', needed
> by 'cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o'.  Stop.
>

If I cd to the same directory on my machine (well, the corresponding
directory, actually), I see the container_test.cpp right where it should be

% pwd
/home/jdanek/repos/qpid/qpid-proton/build
% ls ../cpp/src/container_test.cpp
../cpp/src/container_test.cpp

Is it missing for you? What does `git status` print? It should say pretty
much nothing, only that you are on branch main and that there is untracked
directory build, pretty much. It should not say that any tracked files are
deleted, or so on
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

I still have no idea what's going on. Try to see how container_test gets
produced. Delete it, then run `VERBOSE=1 make`. As a result, the file
should be recreated and you should see a subcommand executed by make that
produced it. Post that here.

On Wed, Apr 7, 2021 at 6:36 PM mehaboob shariff 
wrote:

> no it is executing
>
>
> On Wed, Apr 7, 2021 at 9:36 PM Jiri Daněk  wrote:
>
> > On Wed, Apr 7, 2021 at 6:01 PM mehaboob shariff 
> > wrote:
> >
> > > I built it as given in the INSTALL.md file which seems to be
> > out-of-source
> > > build
> > >
> >
> > But then you report that container_test has been built in-source? Can you
> > actually run it there? ./container_test ?
> > --
> > Mit freundlichen Grüßen / Kind regards
> > Jiri Daněk
> >
>


-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Wed, Apr 7, 2021 at 6:01 PM mehaboob shariff 
wrote:

> I built it as given in the INSTALL.md file which seems to be out-of-source
> build
>

But then you report that container_test has been built in-source? Can you
actually run it there? ./container_test ?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Wed, Apr 7, 2021 at 5:36 PM mehaboob shariff 
wrote:

> There was no container_test in build/cpp earlier so I copied src from
> /qpid-proton/cpp/ and pasted in there. Then ran the command you gave.
>

Allright, so what do we have here. The test is expecting files in the
/build/ dir, but they were actually built in the sources dir. Reminds me of
this difference between in-source and out-of-source builds
https://softwareengineering.stackexchange.com/questions/365460/in-source-build-vs-out-of-source-build

How exactly did you build Proton? Did you build it in-source (git clone
...; cd qpid-proton; cmake .; make) or out of source (git clone ...; cd
qpid-proton; mkdir build; cd build; cmake ...; make)?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Wed, Apr 7, 2021 at 4:41 PM mehaboob shariff 
wrote:

> Is this a mistake I made while building?
>
> On Wed, Apr 7, 2021 at 7:58 PM mehaboob shariff 
> wrote:
>
> > mrrobot@mrrobot:~/Desktop/qpid-proton/build$ ls -ALFh
> > /home/mrrobot/Desktop/qpid-proton/buid/cpp/container_test
> > ls: cannot access
> > '/home/mrrobot/Desktop/qpid-proton/buid/cpp/container_test': No such file
> > or directory
> >
> > but container_test is there in /qpid-proton/cpp/src
>

So, is it 'buid' or 'build'? :P
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

That's seriously weird. What does the following command print?

ls -AlFh /home/mrrobot/Desktop/qpid-proton/build/cpp/container_test

On Wed, Apr 7, 2021 at 4:16 PM mehaboob shariff 
wrote:

> Both the files ( container and container_test ) are there and make was
> worked fine earlier but when I running it again Im getting this issue
>
> On Wed, Apr 7, 2021 at 7:10 PM Jiri Daněk  wrote:
>
> > >
> > > 18: FileNotFoundError: [Errno 2] No such file or directory:
> > > '/home/mrrobot/Desktop/qpid-proton/build/cpp/container_test'
> > >
> >
> > Right. So, is container_test really missing? If so, then it was not
> built.
> > Why it wasn't build? Did you try rerunning make? You can list all make
> > targets (make help, I think), is there something named container_test? Is
> > it possible you somehow disabled building of the test program (it can be
> > done)? ...
> > --
> > Mit freundlichen Grüßen / Kind regards
> > Jiri Daněk
> >
>


-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

>
> 18: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/mrrobot/Desktop/qpid-proton/build/cpp/container_test'
>

Right. So, is container_test really missing? If so, then it was not built.
Why it wasn't build? Did you try rerunning make? You can list all make
targets (make help, I think), is there something named container_test? Is
it possible you somehow disabled building of the test program (it can be
done)? ...
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

I don't see any image, it got dropped from the e-mail on the way,
somewhere. But the exception is a simple text message, so please copy-paste
it into the email as text, that should work more surely.

On Wed, Apr 7, 2021 at 3:21 PM mehaboob shariff 
wrote:

> Is this the one you asked for?
>
> [image: image.png]
>
> On Wed, Apr 7, 2021 at 6:37 PM Jiri Daněk  wrote:
>
>> On Wed, Apr 7, 2021 at 2:11 PM mehaboob shariff 
>> wrote:
>>
>> > Im getting these errors again
>> > 18: Test timeout computed to be: 1500
>> > 18: Traceback (most recent call last):
>> > 18:   File "/home/mrrobot/Desktop/qpid-proton/scripts/env.py", line 68,
>> in
>> > 
>> > 18: sys.exit(main())
>> > 18:   File "/home/mrrobot/Desktop/qpid-proton/scripts/env.py", line 63,
>> in
>> > main
>> > 18: p = subprocess.Popen(args, env=new_env)
>> > 18:   File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
>> > 18: self._execute_child(args, executable, preexec_fn, close_fds,
>> > 18:   File "/usr/lib/python3.8/subprocess.py", line 1702, in
>> _execute_child
>> > 18: raise child_exception_type(errno_num, err_msg, err_filename
>> >
>>
>> You haven't posted the line right after the above, which is the most
>> important line. What exception, actually, got thrown, and what was the
>> errno_num there?
>>
>> See for example the exception traceback at
>>
>> https://stackoverflow.com/questions/49991435/using-python-to-send-subprocess-commands-with-escape-characters
>> ,
>> which has that information.
>>
>> So, what actually went wrong? And if that's a file not exists, then try
>> searching for it (find), or run the build (make) again in case you did not
>> build the file before. I hope that helps, and if not, please provide the
>> requested information from the end of exception I asked for.
>> --
>> Mit freundlichen Grüßen / Kind regards
>> Jiri Daněk
>>
>

-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Wed, Apr 7, 2021 at 2:11 PM mehaboob shariff 
wrote:

> Im getting these errors again
> 18: Test timeout computed to be: 1500
> 18: Traceback (most recent call last):
> 18:   File "/home/mrrobot/Desktop/qpid-proton/scripts/env.py", line 68, in
> 
> 18: sys.exit(main())
> 18:   File "/home/mrrobot/Desktop/qpid-proton/scripts/env.py", line 63, in
> main
> 18: p = subprocess.Popen(args, env=new_env)
> 18:   File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
> 18: self._execute_child(args, executable, preexec_fn, close_fds,
> 18:   File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
> 18: raise child_exception_type(errno_num, err_msg, err_filename
>

You haven't posted the line right after the above, which is the most
important line. What exception, actually, got thrown, and what was the
errno_num there?

See for example the exception traceback at
https://stackoverflow.com/questions/49991435/using-python-to-send-subprocess-commands-with-escape-characters,
which has that information.

So, what actually went wrong? And if that's a file not exists, then try
searching for it (find), or run the build (make) again in case you did not
build the file before. I hope that helps, and if not, please provide the
requested information from the end of exception I asked for.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Doubts regarding setting up development environment

[Jiri Daněk]

On Sat, Apr 3, 2021 at 1:11 PM Srijan  wrote:

> Thank you for taking out time to read my problem precisely.
> About the command line message, it is giving command not found exception
> ('cmake' is not recognized as an internal or external command).


This means that your command line (cmd.exe or powershell, not sure which
one you use) cannot find the cmake program. After you installed CMake (from
https://cmake.org/install/), try specifying a full path to it. Something
like the following, depending on where you installed CMake.

C:\Users\Jiri\Downloads\CMake\bin\cmake ..

If it works for you that way, then investigate how to set the PATH
variable, to put cmake on the search path, so you don't have to specify the
full absolute path to it all the time [1]. Or just continue specifying the
full path. Or install Visual Studio 2019 Community, because it integrates
CMake and should work out of the box [2]. Or install Ubuntu, that should
work too, because when you install CMake in Ubuntu, it will be put on PATH
for you automatically.

[1]
https://superuser.com/questions/284342/what-are-path-and-other-environment-variables-and-how-can-i-set-or-use-them
[2]
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=msvc-160
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Doubts regarding setting up development environment

[Jiri Daněk]

On Sat, Apr 3, 2021, 04:36 Srijan  wrote:

> Hello everyone.
> I followed the steps written in INSTALL.MD file but the terminal kept
> giving
> me cmake error.
> 


The picture I see is tiny and I can't read the error message. Please
copy-paste the text from the terminal into the e-mail. Here's how you do
that on Windows https://superuser.com/a/114

I was thinking about using a linux system but I am not very proficient at
> it.


You'd want to use Ubuntu, just because it probably has the largest
population of beginners using it and they produce lots of beginner
questions on the internet you can find with search engines. Or you can ask
your own and it will be well received, because Ubuntu people are used to
having beginners around.

* https://brb.nci.nih.gov/seqtools/installUbuntu.html Oracle VirtualBox can
be used to run a virtual machine with Ubumtu linux from Windows
* https://ubuntu.com/wsl Windows Subsystem for Linux allows for a faster
and more lightweight way of achieving essentially the same result as
VirtualBox gives you

If you decide to try, then try one of the two ways I've listed. Both are
about running Ubuntu from inside Windows, which is more convenient than the
other methods. WSL2 seems to be the more light-weight option and faster to
get going, if I understand it correctly (I only used VirtualBox previously).

I talked to one of my friends and he insisted on installing turbo cpp


You mean this https://en.wikipedia.org/wiki/Turbo_C%2B%2B ?! That does not
look promising. Qpid Proton's INSTALL.md talks about Visual Studio, which
is what you should install. There is I think a version of Visual Studio
2019 that is free to use.

I decided to work on gitpod and so far all the commands seem to be working
> just fine. However, I would like to know if this was a good idea?


If you can fit your usage into the Free plan thay offer, then I think it's
fine for now. I still recommend installing either Ubuntu (to have your own
Linux environment, for offline work, or if you want to have your IDE open
for more than 50 hours per month and not pay for the privilege) or install
Microsoft Visual Studio and try to get your Windows development environment
to work.

Re: Test mail

[Jiri Daněk]

Hey Srijan, are you here from Outreachy, too?

If that's so, welcome. It's great to see you here!  To get things started,
do you have
a working dev environment, where you can build the Proton C code and run
the tests?

https://github.com/apache/qpid-proton/blob/main/INSTALL.md

There's also recently been some helpful discussion about getting started on
the list here, so if you have trouble, check out what others have done.

Re: outreachy applicant

[Jiri Daněk]

>
> 11:   File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child
> 11: raise child_exception
> 11: OSError: [Errno 2] No such file or directory


If I understand the exception correctly, it comes from a Python script
called "testme" that is trying to run a binary called "broker" as a
subprocess. That "broker" binary is not found.

So, why is it missing? Was it built? Try running `find . -name 'broker'` if
it's somewhere under build/
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Thu, Apr 1, 2021 at 1:20 PM Kajal Sah  wrote:

> Thanks, Jiri. Now, I am able to see why tests are failing. It is probably
> because of missing ruby packages.
>
> Here is the error log
>
>
> /usr/local/lib/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:54:in
> `require': libsasl2.so.3: cannot open shared object file: No such file or
> directory - /usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.5.0/cproton.so
> (LoadError)
>
> How can I go around solving this?
>

Disable the Ruby part of the project, unless you actually want to work on
Qpid Proton Ruby binding ;P Add option -DBUILD_BINDINGS=cpp,python to your
`cmake ..` command. That is, do not specify ruby binding.

If you want to dig into this issue deeper, then try looking at what does
`cmake ...` print regarding sasl, or cyrus sasl? Do you have cyrus sasl
installed?
I am also suspicious of the option -DSYSINSTALL_BINDINGS. Try leaving it
out. CI does not use it either. In fact, for Proton development, you should
not need to install Proton at all, you can work from the build directory.

On Thu, Apr 1, 2021 at 1:20 PM mehaboob shariff 
wrote:

> Hello Jiri,
> Thanks for the information. I don't particularly remember the tests that
> failed that were caused due to absence of Jsoncpp.


I tried running tests without jsoncpp installed (on Fedora Linux) and I did
not see the error you described, so I am not in the best position to
investigate.


> Sorry for the
> inconvenience


No inconvenience on my side, Proton works for me ;P
 --
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: outreachy applicant

[Jiri Daněk]

On Thu, Apr 1, 2021 at 12:05 PM Kajal Sah  wrote:

> Thanks, mehaboob. I was indeed missing JsonCpp but installing that didn't
> help either. Apart from that, I think I have all the libraries and packages
> installed. Somehow, I think getting error log of the failing tests will
> help me debug better.
>

That is probably the reason CI does not run `make test`, but it instead
does `cd build; ctest -VV`. At the least, you'd see printed the exact
command that is executed to run the tests, so you can then use it to run
the binary in a debugger yourself (if you get a segfault before)...

If you do `make test`, then there might be some kind of more telling log in
build/Testing directory, but I cannot vouch for that. I always used ctest
-VV with CMake projects, never `make test`.

I'd be interested in knowing what the test errors without jsoncpp were...

Re: outreachy applicant

[Jiri Daněk]

On Thu, Apr 1, 2021, 03:16 Kajal Sah  wrote:

> Hi,
>
> I am also getting errors when I try to test the coverage. I followed both
> the steps mentioned above by Rakhi and Justin. I have lcov installed
> already.
>
> Some information: Most of the test in make test fails (only 7% passes, i.e.
> 42 out of 45 failed).


I'd start here. Tests fail how? What errors are printed from failing tests?

Re: outreachy applicant

[Jiri Daněk]

One helpful strategy. If in doubt how to build, look how the CI does it.
These commands run for every commit in CI, so it is likely they will work
and will be up to date. C stands for Continuous, after all.

What you find may be needlessly complicated (you will see below), but
that's what works on the CI machine.

Proton happens to have 4 different CI configs, for 4 different CIs (plus a
Jenkins CI job which is not checked into repo)
*
https://github.com/apache/qpid-proton/blob/main/.github/workflows/build.yml
* https://github.com/apache/qpid-proton/tree/main/azure-pipelines
* https://github.com/apache/qpid-proton/blob/main/.appveyor.yml
* https://github.com/apache/qpid-proton/blob/main/.travis.yml

The relevant part for coverage is

1) install lcov,
https://github.com/apache/qpid-proton/blob/5d3473dd484090590863c0d87dea4ea91bba87dc/.travis.yml#L140
2) set build type to Coverage,
https://github.com/apache/qpid-proton/blob/5d3473dd484090590863c0d87dea4ea91bba87dc/.travis.yml#L97
3) make coverage, but that's not there, because the CI does this
differently (collects coverage data and uploads it to a service)
https://github.com/apache/qpid-proton/blob/5d3473dd484090590863c0d87dea4ea91bba87dc/.travis.yml#L99

On Wed, Mar 31, 2021, 19:50 mehaboob shariff  wrote:

> I am running it from the build directory.
> Can I know which distro of linux you are using?
>
> On Wed, Mar 31, 2021 at 11:08 PM Rakhi Kumari 
> wrote:
>
> > Hey mehaboob!!
> > Can you please tell us from which directory you are running the make
> > command? As I am not able to see the image that you have shared.
> > Btw I am running the make command from inside the build directory.
> >
> > On Wed, Mar 31, 2021 at 10:32 PM mehaboob shariff  >
> > wrote:
> >
> > > So I removed the build directory and did the process again.
> > > This time I got this error
> > > [image: image.png]
> > >
> > > On Wed, Mar 31, 2021 at 10:23 PM mehaboob shariff <
> mehaboob...@gmail.com
> > >
> > > wrote:
> > >
> > >> Thank you Rakhi and Justin.
> > >> Rakhi I ran it in the similar sequence. But there seem to be other
> > issues
> > >> so im getting  "make: *** No rule to make target 'coverage'.  Stop."
> > >>
> > >>
> > >> On Wed, Mar 31, 2021 at 9:49 PM Justin Ross 
> > >> wrote:
> > >>
> > >>> Ah!  Rakhi ninjaed me. ;)
> > >>>
> > >>> On Wed, Mar 31, 2021 at 12:17 PM Justin Ross 
> > >>> wrote:
> > >>>
> > >>> > Here's the sequence I use:
> > >>> >
> > >>> >  - cd qpid-proton
> > >>> >  - mkdir bld
> > >>> >  - cd bld
> > >>> >  - cmake .. -DCMAKE_BUILD_TYPE=Coverage
> > >>> >  - make build
> > >>> >
> > >>> > You don't need the CMakeLists.txt file where you run cmake
> > >>> (necessarily).
> > >>> > You need it for the source tree you are configuring (referenced by
> > >>> ".." in
> > >>> > the cmake command above).
> > >>> >
> > >>> > On Wed, Mar 31, 2021 at 12:00 PM mehaboob shariff <
> > >>> mehaboob...@gmail.com>
> > >>> > wrote:
> > >>> >
> > >>> >> Could you provide some insights on how to configure the build for
> > >>> coverage
> > >>> >> because when run the cmake it shows there is no CMakeList.txt file
> > in
> > >>> the
> > >>> >> build directory.
> > >>> >> So I navigated to /build/CMakeFiles/CheckCXX and ran the command
> but
> > >>> there
> > >>> >> seems to be no output
> > >>> >>
> > >>> >> On Wed, Mar 31, 2021 at 7:45 PM mehaboob shariff <
> > >>> mehaboob...@gmail.com>
> > >>> >> wrote:
> > >>> >>
> > >>> >> > Tahnk you Justin, will get back to you if I face any troubles
> > >>> >> >
> > >>> >> > On Wed, Mar 31, 2021 at 6:59 PM Justin Ross <
> > justin.r...@gmail.com>
> > >>> >> wrote:
> > >>> >> >
> > >>> >> >> Hi, Mehaboob.  Here's one to try:
> > >>> >> >> https://issues.apache.org/jira/browse/PROTON-2358
> > >>> >> >>
> > >>> >> >> Please tell us about any obstacles you face.
> > >>> >> >>
> > >>> >> >> On Tue, Mar 30, 2021 at 4:56 PM mehaboob shariff <
> > >>> >> mehaboob...@gmail.com>
> > >>> >> >> wrote:
> > >>> >> >>
> > >>> >> >> > okay, thank you for the information
> > >>> >> >> >
> > >>> >> >> > On Wed, Mar 31, 2021 at 2:08 AM Justin Ross <
> > >>> justin.r...@gmail.com>
> > >>> >> >> wrote:
> > >>> >> >> >
> > >>> >> >> > > You don't have too, but in particular I think you may end
> up
> > >>> >> wanting
> > >>> >> >> the
> > >>> >> >> > > Python binding since some tests use it.
> > >>> >> >> > >
> > >>> >> >> > > On Tue, Mar 30, 2021 at 3:25 PM mehaboob shariff <
> > >>> >> >> mehaboob...@gmail.com>
> > >>> >> >> > > wrote:
> > >>> >> >> > >
> > >>> >> >> > > > Do we have to install the language bindings in the
> > >>> instructions.
> > >>> >> If
> > >>> >> >> not
> > >>> >> >> > > > then I have compiled the proton source repo successfully
> > >>> >> >> > > >
> > >>> >> >> > > >
> > >>> >> >> > > > On Wed, Mar 31, 2021 at 12:51 AM Justin Ross <
> > >>> >> justin.r...@gmail.com
> > >>> >> >> >
> > >>> >> >> > > > wrote:
> > >>> >> >> > > >
> > >>> >> >> > > > > Okay, next is to use git to fetch the Qpid Proton C
> > source
> > >>> repo
> 

Re: Autopep8 for DISPATCH-1814

[Jiri Daněk]

On Fri, Nov 6, 2020 at 3:15 PM Ken Giusti  wrote:

> On Fri, Nov 6, 2020 at 5:40 AM Robbie Gemmell 
> wrote:
>
> > On Thu, 5 Nov 2020 at 15:32, Jiri Daněk  wrote:
> > >
> > > Hello folks,
> > >
> > > (https://issues.apache.org/jira/browse/DISPATCH-1814 Apply autofixes
> to
> > > resolve some flake8 code formatting issues)
> > >
> > > I have prior positive experience with autopep8,
> > > https://pypi.org/project/autopep8/. It is a tool to automatically
> > reformat
> > > Python source code. It can either selectively reformat to fix only a
> > > specific flake8 warning, or it can just do it all in one go.
> > >
> > > What do you think about running this on the Qpid Proton and Qpid
> Dispatch
> > > code? Is there a good time when to do it? Would it be better to fix
> each
> > > warning individually, in its own commit (to simplify manual review), or
> > do
> > > it all in one commit (to simplify git history, and spend less time on
> > it)?
> > >
> > > I am personally in favour of a single commit in which to do all the
> > > whitespace changes in one go. I've always found autopep8 to work
> > reliably.
> > >
> > > Regarding potential issues, whitespace changes would affect ongoing
> work
> > in
> > > progress (although the autoformatter can be run on the PRs as well), so
> > it
> > > seems to me that a good time to land this would be after a release.
> > > --
> > > Mit freundlichen Grüßen / Kind regards
> > > Jiri Daněk
> >
> > I'll leave 'what to do?' position to the folks with more knowledge /
> > actually working on the bits, but I think you nailed the answer to
> > 'when to do it?' aspect already: if doing anything like this an agreed
> > point just after a release seems to be clearly the best time for such
> > things.
> >
> > Robbie
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
> I agree with Robbie in terms of when (shortly after a new release).
>
> I'm in favor of doing this and would prefer a single commit if possible.
> -K
>

Autopep8 fixes are applied now for Proton and Dispatch, in
https://issues.apache.org/jira/browse/PROTON-2320 and
https://issues.apache.org/jira/browse/DISPATCH-1814. In case of dispatch I
decided not to apply the autofixes which would remove vertical alignment in
Python sources. (Removal of multiple spaces before/after a comma, colon,
etc.)

There are follow-up jiras for reducing the number of flake8 suppressions in
tox.ini, https://issues.apache.org/jira/browse/PROTON-2322 and
https://issues.apache.org/jira/browse/DISPATCH-1974.

I decided not to do this for the Qpid Cpp Broker, because the releases
there are infrequent.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

[Discuss] What's the status of -DSYSINSTALL_BINDINGS option in Qpid Proton (and other bindings?)

[Jiri Daněk]

I remember hearing somewhere that the option  -DSYSINSTALL_BINDINGS in
Proton is deprecated or should be considered deprecated.

I am confused about this, for two reasons. First, this is essentially what
any RPM/DEB packaging relies on when packages are built. Second, Dispatch
depends on the unpacked Proton Python build during ctest testing in
development, not on the wheel.

I did not find any notice or mention whatsoever that -DSYSINSTALL_BINDINGS
is deprecated.

Can anyone please clarify?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Is there any Qpid Dispatch Router windows version?

[Jiri Daněk]

Visual Studio supports multiple compilers! Besides MSVC it is also possible
to use Clang, and supposedly GCC with Visual Studio 2019 [1]. This is good,
because it somewhat reduces the number of incompatible things that would
have to be fixed to compile Dispatch on Windows.

I just spent some time trying to compile on Windows 10 with Clang. I had to
change 22 files, usually small changes fixing header-file includes,
replacing POSIX constructs with either a no-op implementation (e.g. the
backtrace printing in alloc_pool.c) or with Windows-compatible
implementations that I was able to find on the internet (full-StackOverflow
development is a thing!). In total, I've touched 22 files and managed to
get it to compile, but not (yet) to link, since I sometimes just threw in
function declarations without implementations; I did that especially for
pthreads.

There are projects like PHP or PostgreSQL that implement various
multiplatform shims to support both POSIX and Windows in a single codebase.
That is possibly a great source of inspiration.

The largest area missing on Windows was pthreads, and the second largest
functions about system clock and time. All threading code is in
threading.c; time code is spread out more. There are reimplementations of
pthreads for Windows, I am sure something with a suitable licence can be
copy-pasted in. Licence is a problem. Dispatch may not vendor on any
GPL-licensed code.

Next up, there are likely going to be problems with making the tests work.
I did not get to trying that, so I don't know how hard that might be.

All in all, porting the C code for Windows looks quite doable, but it
pollutes the code with multiplatform constructs and indirection (including
platform-dependent versions of headers). I imagine having to care about
Windows would slow down POSIX development; the maintenance costs are
undeniable. Few well-placed macros could even make it work on MSVC, but
again, macros make things harder to work with.

Personally, I feel that supporting Windows does not pay off for the Qpid
Dispatch project as a whole. I haven't seen any user interest, except this
thread. The IOCP proactor in Proton might benefit though, since Dispatch
would exercise the Windows code. Compiling under Cygwin and maintaining
that ability is probably a better practical proposition anyways, if there
is inclination to support something on Windows. Or maybe just using Linux
for Dispatch. Azure will run Linux just fine. But all that is just my
personal opinion.

[1]
https://docs.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-160

Re: How to supply a patch for qpid-proton examples

[Jiri Daněk]

On Fri, Jan 22, 2021 at 8:47 AM Thomas Kettenbach 
wrote:

> As i am new to this, i'd like to understand how i could provide a patch for
> this? I would not like to open an issue via jira, as it is really just a
> minor issue. So far, i understand that the examples are just to demonstrate
> the usage of the cpp Bindings of qpid-proton, and they are usually run via
> the testme.py script.
>

Jira is used to generate release notes for a release, so we do need it, to
mark that examples were improved. If you'd rather not create it, it is OK
to just submit a patch in a GitHub Pull Request, against
https://github.com/apache/qpid-proton. Whoever ends up merging this will
then create a Jira for it.

One advantage of filling a jira is that it forces you to describe your
problem up front. That can make understanting the patch easier, or it can
point out to other directions for solving the problem. Not that this is
likely the case, if it's really about a minor issue in an example.

Happy contributing, cheers,
Jiri!

Re: Is there any Qpid Dispatch Router windows version?

[Jiri Daněk]

On Tue, Jan 5, 2021, 10:32 Gordon Sim  wrote:

> On 04/01/2021 09:34, Jiri Daněk wrote:
> > Hi, a long time ago, i saw Dispatch running in Windows Subsystem for
> Linux.
> > That could be a practical option. The rest of this email is more or less
> > far fetched speculation from me.
>
> Running as a docker container could be another option.
>

I was hesitant to propose this, because Docker on Windows involves a Linux
virtual machine which runs the actual program. Docker just provides
convenient UI around it.

But I imagine it could be actually practical setup, especially because of
the friendly Docker UI, which makes things so much more convenient that
running a VM on a Windows host yourself.

>

Re: Is there any Qpid Dispatch Router windows version?

[Jiri Daněk]

Hi, a long time ago, i saw Dispatch running in Windows Subsystem for Linux.
That could be a practical option. The rest of this email is more or less
far fetched speculation from me.

Another possibility would be Cygwin environment (which would provide POSIX
Threads, and OpenSSL, and such)

Finally, i saw there even are some POSIX Threads libraries for Windows
itself. One more thing, threading in Dispatch is compartmentalized into
functions in a single file, so maybe that file could be replaced with a
windows specific one.

Besides posix Threads and maybe OpenSSL, another dependency is Linux epol
proactor in Qpid Proton, that is used by Dispatch. It might be possible to
use the IOCP or libuv versions of the proactor, but that's something that
is not normally done.

https://en.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux

https://en.m.wikipedia.org/wiki/Cygwin


On Mon, Jan 4, 2021, 06:57 mohank  wrote:

> Hi,
>
> We are mainly in to Windows application development.
>
> We got suggestion to use Qpid Dispatch Router to scale up the AMQP
> connections(i.e. connections are b/w 5000 - 1)
>
> As per the documentation QPID Dispatcher "Note : Dispatch Router will not
> build
> on Windows."
>
> Is there any Windows Qpid Dispatch Router version to install OR is there
> any
> way to install the same in Windows.
>
> Thanks,
> Mohan
>
>
>
> --
> Sent from:
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [NOTICE] Travis CI .org -> .com move, action required.

[Jiri Daněk]

On Wed, Dec 2, 2020 at 1:12 PM Robbie Gemmell 
wrote:

> > > > > Qpid Dispatch has a mac build and it looks like we might have to
> pay for
> > > > it
> > > > > if we want to keep it around by purchasing what they
> > > > > call credits (1 minute of mac build time costs 50 credits). Do we
> want to
> > > > > do this? Or are we just going to drop the mac os builds?
> > > > >
> > > >
> > > > We would surely drop it from the Travis build in that case.
> > > >
> > > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > > could be updated to use them if desired.
> > > >
> > >
> > > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> > >
> > > We'll probably want to make the same change in Proton as well.
> >
> > For the removal from Travis, yep. The GHA build for Proton already
> > runs on OSX currently as you no doubt know.
>
>
> I ended up raising a JIRA for this,
> https://issues.apache.org/jira/browse/INFRA-21154, which has now been
> actioned. All the repository jobs have now been migrated to the .com
> site.
>
> I have prodded the various jobs to run, updating some READMEs and the
> website to use links/badges from the .com site. Once they run, the
> .org site updates to say only that the jobs were migrated and give a
> link to the .com site.
>
> The OSX elements of the Proton and Dispatch builds did execute,
> whereas I expected the job to error immediately. This could be as the
> ASF's plan has some life left (seems pricing migration happens at
> plan-end), or they've got some OSX credits, unclear. I have asked
> about those on the Infra JIRA to see what expectations are going
> forward.
>
> From a quick test I did the migration within the apache github org
> seems to have no effect on our forks, which makes sense. This means
> your forks with .org enabled builds will continue to try building
> there, with its dwindling resources, until it goes defunct on Dec
> 31st. If you dont migrate or enable your fork build on the .com site
> it simply won't build after that presumably.
>

I've spent some time on migrating the Dispatch macOS Travis job to GitHub
Actions and I got stuck on a freeze that I was unable to debug. I found
some working GitHub Actions that are using MacPorts, so as a next step I
would be trying to steal working bits from those. Alternatively, I could
drop MacPorts and use Brew, and either build Cyrus SASL myself, or just
live without it {SASL itself is part of macOS, but it is deprecated, and
the utility programs to manage the DB are missing).

Link to the stuck Action,
https://github.com/jiridanek/qpid-dispatch/runs/1473498467?check_suite_focus=true
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [NOTICE] Travis CI .org -> .com move, action required.

[Jiri Daněk]

On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell 
wrote:

> On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy  wrote:
> >
> > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > wrote:
> >
> > > Hi folks,
> > >
> > > Short version:
> > > 1) The Travis build jobs will migrate to a new URL, on their .com site
> > > rather than .org, links etc will need to be updated.
> > > 2) Travis have introduced relatively tiny default resource limits for
> > > free users, so you may want to disable Travis on your Github forks to
> > > save them until really needed (or you can apparently individually
> > > apply for a higher limit).
> > >
> > > Expanded version:
> > > First up, as some of you may know Travis CI is migrating away from use
> > > of https://travis-ci.org to solely using their other
> > > https://travis-ci.com site. This has been underway for many years at
> > > this point with no real traction, but a final deadline of Dec 31st has
> > > been set for the .org bits to become defunct, and worker nodes have
> > > been migrating across for weeks now, so the point has come a switch is
> > > required.
> > >
> > > When done, the existing URLs will just give a landing page saying the
> > > build moved, with a link to go to it. Folks using the existing URLs
> > > for build status etc will need to update their references.
> > >
> > > Infra started to migrate some jobs over themselves, and also migrate
> > > the paid ASF concurrency limits plan across for the apache github org.
> > > They decided they didnt want to end up migrating >2000 jobs when many
> > > aren't really used anymore, and so have asked for the remainder that
> > > migrations be requested.
> > >
> > > None of ours appear to have been moved yet, so I have requested [1]
> > > that infra do the migration for these repositories:
> > > qpid-broker-j
> > > qpid-dispatch
> > > qpid-jms
> > > qpid-proton
> > > qpid-proton-j
> > > qpid-site
> >
> > Thanks for doing this! So it looks like no other additional action is
> > required on our side.
> > Once this migration is complete, we will be as usual able to access the
> > Travis
> > builds from the github <https://github.com/apache/qpid-dispatch> website
> > with the just the one difference that the Travis build URLs
> > will point to the .com website.
> >
>
> Should be the case yep.
>
> > With regards to the resource limits on forks, it looks like we will have
> to
> > wait to see if they automatically
> > enable  builds or if they will make us enable it. If they don't enable
> it,
> > I don't plan on enabling it.
> > Again, no action required from our side if they don't enable it.
> >
>
> Yep.
>
> > Qpid Dispatch has a mac build and it looks like we might have to pay for
> it
> > if we want to keep it around by purchasing what they
> > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > do this? Or are we just going to drop the mac os builds?
> >
>
> We would surely drop it from the Travis build in that case.
>
> GitHub Actions also has MacOS build nodes, so that build workflow
> could be updated to use them if desired.
>

Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855

We'll probably want to make the same change in Proton as well.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Autopep8 for DISPATCH-1814

[Jiri Daněk]

Hello folks,

(https://issues.apache.org/jira/browse/DISPATCH-1814 Apply autofixes to
resolve some flake8 code formatting issues)

I have prior positive experience with autopep8,
https://pypi.org/project/autopep8/. It is a tool to automatically reformat
Python source code. It can either selectively reformat to fix only a
specific flake8 warning, or it can just do it all in one go.

What do you think about running this on the Qpid Proton and Qpid Dispatch
code? Is there a good time when to do it? Would it be better to fix each
warning individually, in its own commit (to simplify manual review), or do
it all in one commit (to simplify git history, and spend less time on it)?

I am personally in favour of a single commit in which to do all the
whitespace changes in one go. I've always found autopep8 to work reliably.

Regarding potential issues, whitespace changes would affect ongoing work in
progress (although the autoformatter can be run on the PRs as well), so it
seems to me that a good time to land this would be after a release.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [NOTICE] Jenkins CI server change, manual job migrations required

[Jiri Daněk]

On Fri, Jul 24, 2020 at 2:39 PM Robbie Gemmell 
wrote:
[...]

> We must manually migrate any jobs we want to keep to the new system.


Are the job definitions in the new system under version control, or is
there expectation to manage jobs through the Web UI?

 [...]

> I asked for a Qpid folder and for all committers to have access to the
> jobs, where they will live under:
> https://ci-builds.apache.org/job/Qpid/
>
> Our old jobs are at: https://builds.apache.org/view/M-R/view/Qpid/


Are there any advantages to using the Apache infra, over Travis or AppVeyor
or GitHub Actions? So far I've managed to completely ignore the Apache
Jenkins, so I am wondering; am I missing something? Maybe some Cloudbees
proprietary plugins?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: qpid-cpp-server 1.36 for CentOS6/RHEL6

[Jiri Daněk]

There are EPEL packages for el7, but not for el6.
https://qpid.apache.org/packages.html#epel

I'd download the src.rpm from the el7 epel, at
https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/q/qpid-cpp-1.39.0-1.el7.src.rpm,
notice that the .spec file there makes provisions for rhel<7, which means 6
;], and build it myself, by running `rpmbuild --rebuild
qpid-cpp-1.39.0-1.el7.src.rpm`.

If I needed specifically the 1.36 version, I'd go hunting for the .src.rpm
at https://cbs.centos.org/koji/packageinfo?packageID=405.

`yum install yum-utils; yum-builddep qpid-cpp-1.39.0-1.el7.src.rpm` will
install build dependencies for you. Qpid Proton is available in the el6
epel.

Hopefully the package will just build, without any issues. I did not try it
myself.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [VOTE] Release Apache Qpid Proton 0.31.0 (RC2)

[Jiri Daněk]

+1

* Validated checksum
* Built from source on Raspberry PI 4 (Raspbian Buster, 32bit and Ubuntu
20.04, 64 bit) with gcc and clang, and ran the test suite
* Ran python tox test on that Ubuntu

Notes:

# Got compilation failure with clang-10 on Ubuntu; it compiled fine with
clang-9 and gcc

[ 23%] Building C object c/examples/CMakeFiles/c-send-ssl.dir/send-ssl.c.o
cd /home/ubuntu/repos/qpid-proton-0.31.0/clangrelease/c/examples &&
/usr/bin/clang-10  -I/home/ubuntu/repos/qpid-proton-0.31.0/c/include
-I/home/ubuntu/repos/qpid-proton-0.31.0/c/src
-I/home/ubuntu/repos/qpid-proton-0.31.0/clangrelease/c
/include -I/home/ubuntu/repos/qpid-proton-0.31.0/clangrelease/c/src  -O2 -g
-DNDEBUG   -Werror -Wall -pedantic -std=iso9899:1990 -pedantic -o
CMakeFiles/c-send-ssl.dir/send-ssl.c.o   -c
/home/ubuntu/repos/qpid-proton-0.31.0/c/examples/send-ssl.c
In file included from
/home/ubuntu/repos/qpid-proton-0.31.0/c/examples/send-ssl.c:22:
In file included from
/home/ubuntu/repos/qpid-proton-0.31.0/c/include/proton/connection.h:26:
In file included from
/home/ubuntu/repos/qpid-proton-0.31.0/c/include/proton/codec.h:26:
/home/ubuntu/repos/qpid-proton-0.31.0/c/include/proton/object.h:206:11:
error: '_Bool' is a C99 extension [-Werror,-Wc99-extensions]
PN_EXTERN bool pn_class_equals(const pn_class_t *clazz, void *a, void *b);
/usr/lib/llvm-10/lib/clang/10.0.0/include/stdbool.h:15:14: note: expanded
from macro 'bool'


#define bool _Bool

# Got a failing Go test on Raspbian. It looks to be affecting only 32bit
systems. It was not fixed for me by
https://github.com/apache/qpid-proton/pull/233

$ go version
go version go1.11.6 linux/arm

 --- FAIL: TestPrimitivesCompatible (0.00s)
interop_test.go:66: Decode failed cannot unmarshal AMQP ulong to Go uint
interop_test.go:66: Decode failed cannot unmarshal AMQP ulong to Go int
interop_test.go:66: Decode failed cannot unmarshal AMQP ulong to Go
float64
interop_test.go:66: Decode failed cannot unmarshal AMQP ulong to Go
float64

# On Ubuntu, tox test which was reported as testing with python 2.6 was
apparently using python 3.8; I investigated because I don't have python 2.6
installed in the system, wanted to know how tox got to it; it actually did
not!

python/.tox$ ls */bin/python*
py26/bin/python  py26/bin/python3  py26/bin/python3.8  py27/bin/python
 py27/bin/python2  py27/bin/python2.7  py38/bin/python  py38/bin/python3
 py38/bin/python3.8

# Additional warning from swig wrapper, in Ruby, with swig 4.0.1; there is
a ton of warnings from the wrappers, especially when compiling the Python
wheel

[ 99%] Building C object
ruby/CMakeFiles/cproton-ruby.dir/cprotonRUBY_wrap.c.o
In file included from /usr/include/string.h:495,
 from
/home/ubuntu/repos/qpid-proton-0.31.0/gcc/ruby/cprotonRUBY_wrap.c:441:
In function ‘strncpy’,
inlined from ‘Pn_rbkey_set_key_value’ at
/home/ubuntu/repos/qpid-proton-0.31.0/gcc/ruby/cprotonRUBY_wrap.c:2431:3:
/usr/include/aarch64-linux-gnu/bits/string_fortified.h:106:10: warning:
‘__builtin_strncpy’ specified bound depends on the length of the source
argument [-Wstringop-overflow=]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
(__dest));
  |
 ^~
/home/ubuntu/repos/qpid-proton-0.31.0/gcc/ruby/cprotonRUBY_wrap.c: In
function ‘Pn_rbkey_set_key_value’:
/home/ubuntu/repos/qpid-proton-0.31.0/gcc/ruby/cprotonRUBY_wrap.c:2431:40:
note: length computed here
 2431 |   strncpy(rbkey->key_value, key_value, strlen(key_value) + 1);
  |^

# Got a warning when compiling with GCC 8.3.0 on Raspbian (no such warning
with clang-9 there, or with GCC in Ubuntu)

Scanning dependencies of target py_pkg_wheel
running bdist_wheel
running build
running build_py
running build_ext
running configure
Did not find libqpid-proton-core via pkg-config:
Building the bundled proton-c sources into the extension
Using openssl version 1.1.1d (found via pkg-config)
creating build
creating build/temp.linux-armv7l-2.7
creating build/temp.linux-armv7l-2.7/tmp
cc -c /tmp/sasl_client_doneEcGiwW.c -o
build/temp.linux-armv7l-2.7/tmp/sasl_client_doneEcGiwW.o
/tmp/sasl_client_doneEcGiwW.c:2:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
 main (int argc, char **argv) {
 ^~~~
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: golang/electron

[Jiri Daněk]

On Thu, Apr 9, 2020 at 1:08 PM mpup371  wrote:

> Hello,
> I am not sure I write to the right list, but I think it's worth at least to
> try :-)
>
> I am learning to use the electron API in Go.
> Starting from the examples codes on github, I discover a way to crash the
> broker from the sender.
> I would like to know where I can submit the issue ?
>

Hi, the place would be the Apache Jira, at
https://issues.apache.org/jira/projects/PROTON/issues. Select PROTON as the
Project and go-binding as Component. There is a "Report a bug" link at
https://qpid.apache.org/proton/ that prefils the Project in the issue form.

Thank you for taking the time!
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [DISCUSS] Configure description, homepage, and labels (tags) for qpid repos on GitHub

[Jiri Daněk]

> I've created initial proposal for such file for qpid-proton
>
> https://github.com/apache/qpid-proton/pull/193
>
> The proposed .asf.yaml says
>

Here's .asf.yaml for qpid-dispatch,
https://github.com/apache/qpid-dispatch/pull/577.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

[DISCUSS] Configure description, homepage, and labels (tags) for qpid repos on GitHub

[Jiri Daněk]

Hi folks,

a while ago, support for .asf.yaml config file was announced by the Apache
Infra team. This file, when placed in the root of a project repository,
configures various infrastructure settings which were previously handled
only by raising support tickets. One of those settings concerns the GitHub
repository metadata of the project.

Project description, homepage, and labels (tags) can be configured.

https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Githubrepositorymeta-data

I've created initial proposal for such file for qpid-proton

https://github.com/apache/qpid-proton/pull/193

The proposed .asf.yaml says

```
github:
  description: "Mirror of Apache Qpid Proton"
  homepage: https://qpid.apache.org/proton
  labels:
- qpid
- amqp
- messaging
- library
- apache

- amqp-client
- amqp-connection
- amqp-messages
- amqps
- amqp10

- c
- cpp
- golang
- ruby
- python
- python2
- python3
```

Current values for these fields can be seen at the repo GitHub page

https://github.com/apache/qpid-proton

I'd be interested in any feedback about the description and labels fields.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [Proton-C] Discovery

[Jiri Daněk]

On Wed, Jun 5, 2019 at 12:13 PM Rabih M  wrote:

> Hello Alan,
>
> Will your pull request "reconnect_update" be released in the next proton
> release 0.29.0?
> We are waiting for this dev to implement some features form our side.
>
> We can help if needed...
>

Hi, the PRs on https://issues.apache.org/jira/browse/PROTON-2040 were
merged in time for 0.29 release. Does the way it is implemented there suit
your needs?
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Welcome Jiri Danek as an Apache Qpid committer

[Jiri Daněk]

On Fri, Mar 1, 2019 at 11:12 AM Robbie Gemmell 
wrote:

> The Qpid PMC have voted to grant commit rights to Jiri Danek in
> recognition of continued contributions to the project.
>
> Welcome, Jiri!
>
> Robbie
>

Hello everyone,

thanks very much, glad to be on board!
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: [NOTICE / DISCUSS] migrating Git repositories to gitbox.apache.org

[Jiri Daněk]

Never mind, comment on the migration Jira says that the link redirect will
be taken care of! Awesome.

On Mon, Dec 10, 2018 at 5:10 PM Robbie Gemmell 
wrote:
[...]

> Unless there is discussion here resulting in decision to delay, I will
> raise the migration request JIRA with Infra on Thursday 13th Dec,
> hopefully allowing completion of the process by the end of this week
> if they have bandwidth to do so.
>
[...]

This broke old links in the automatic Apache Jira comments by
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jira-bot with
links to related commits. See e.g. those on
https://issues.apache.org/jira/browse/PROTON-1979.

It seems that a broken link in the form of

https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5ba471d

can be rewritten to a working link

https://gitbox.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=5ba471d

I doubt that the migration will include fixing all the jira comments for
outdated links, though. Or introducing redirect from the old url.
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk

Re: Go Electron: Large Messages Fail To Send

[Jiri Daněk]

On Fri, Oct 19, 2018 at 2:10 PM Gordon Sim  wrote:

> On 19/10/18 12:13, rk wrote:
> > Using the python client I can send much larger messages than 16k to the
> same
> > broker so it appears to be an issue with the Go bindings.
> >
> > The issue can be recreated by editing the example send.go file in the
> > electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
> >
> > I am using version 1.38.0 of qpidd running on Centos 7 and the Go is
> bring
> > compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
> > library.
> >
> > My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
> > why qpidd thinks it hasn't got the delivery so any help much appreciated.
>

I got a similar issue with ActiveMQ Artemis a while back.
https://issues.jboss.org/browse/ENTMQCL-458
-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk