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
>

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

[Daniil Kirilyuk]

+1

On Fri, 12 Jan 2024 at 18:54, Timothy Bish  wrote:

> On 1/12/24 11: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,
>
> +1
>
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

[ANNOUNCE] Apache Qpid protonj2 1.0.0-M19

[Timothy Bish]

The Apache Qpid (http://qpid.apache.org) community is pleased to
announce the immediate availability of Apache protonj2 1.0.0-M19.

This is the latest release of our AMQP Java client supporting the
Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464,
http://www.amqp.org), based around the Apache Qpid ProtonJ2 protocol
engine also contained in this release.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-protonj2-1.0.0-M19/release-notes.html

Thanks to all involved,

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

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

[Timothy Bish]

On 1/12/24 11: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,


+1


--
Tim Bish


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

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

[Robbie Gemmell]

+1

On Fri, 12 Jan 2024 at 16:12, 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

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

[RESULT][VOTE] Release Apache Qpid protonj2 1.0.0-M19

[Timothy Bish]

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


I will add the files to the dist release repo and release the maven
staging repo shortly. The website will be updated after the release
has had time to sync to the mirrors and maven central.

--
Tim Bish


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

[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: Azure event hub consumer groups support in Apache Qpid Proton C++

[Arun Koshal]

Thanks for responding Robbie!

I have figured out a way to consume events from Azure event hub consumer
group by using consumer group in the connection URL. This means that we can
use connection URL like *amqps://.servicebus.windows.net/
/ConsumerGroups//Partitions/*
.

Thanks and regards,
Arun

On Fri, Jan 12, 2024 at 5:11 PM Robbie Gemmell 
wrote:

> I'm not sure how many folks here will be familiar enough with Azure
> Event Hub consumer groups to be able to answer that specifically. I
> know I'm not.
>
> Do Microsoft's own AMQP 1.0 Event Hub clients support consuming from
> such groups? Maybe consult their docs to see what they do? If they do
> support it but dont give enough clarity around what needs done
> protocol-wise, then perhaps you could use their clients to consume
> from such groups and establish what they actually do. Last I knew,
> their Java clients used the Qpid Proton-J engine underneath, so if for
> example they can do it then potentially you could mimic what their
> client does whilst using Proton C++ instead.
>
> On Thu, 11 Jan 2024 at 17:05, Arun Koshal  wrote:
> >
> > Hi,
> >
> > We are using Apache Qpid Proton C++ library version 0.37 in our
> > containerized application which subscribes for events from Azure event
> hub.
> > At present, we are not able to run more than 5 instances of the
> application
> > because Azure event hub does not allow more than 5 receivers in one
> > partition.
> >
> > In order to solve this issue, we plan to configure multiple consumer
> groups
> > in Azure event hub, so that different application instances can consume
> > events from different consumer groups. Does Apache Qpid Proton C++
> version
> > 0.37 support consuming events from Azure event hub consumer groups? It
> > would be really helpful if someone can share some relevant documentation
> or
> > example code to help us modify our application to consume events from
> Azure
> > event hub consumer groups.
> >
> > Thanks and regards,
> > Arun
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Azure event hub consumer groups support in Apache Qpid Proton C++

[Robbie Gemmell]

I'm not sure how many folks here will be familiar enough with Azure
Event Hub consumer groups to be able to answer that specifically. I
know I'm not.

Do Microsoft's own AMQP 1.0 Event Hub clients support consuming from
such groups? Maybe consult their docs to see what they do? If they do
support it but dont give enough clarity around what needs done
protocol-wise, then perhaps you could use their clients to consume
from such groups and establish what they actually do. Last I knew,
their Java clients used the Qpid Proton-J engine underneath, so if for
example they can do it then potentially you could mimic what their
client does whilst using Proton C++ instead.

On Thu, 11 Jan 2024 at 17:05, Arun Koshal  wrote:
>
> Hi,
>
> We are using Apache Qpid Proton C++ library version 0.37 in our
> containerized application which subscribes for events from Azure event hub.
> At present, we are not able to run more than 5 instances of the application
> because Azure event hub does not allow more than 5 receivers in one
> partition.
>
> In order to solve this issue, we plan to configure multiple consumer groups
> in Azure event hub, so that different application instances can consume
> events from different consumer groups. Does Apache Qpid Proton C++ version
> 0.37 support consuming events from Azure event hub consumer groups? It
> would be really helpful if someone can share some relevant documentation or
> example code to help us modify our application to consume events from Azure
> event hub consumer groups.
>
> Thanks and regards,
> Arun

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

Re: Get messages sent not confirmed by broker

[Robbie Gemmell]

Its not clear which client you are using so its hard for anyone to
offer specific advice, however in thinking, I dont believe any of the
clients has a way to retrieve unsettled messages. Related to that, I
believe in most cases the clients dont retain messages to be able to
'retransmit', mostly for some they might freshly transmit things they
hadn't sent before a disconnect (there may be specific outliers to
this, e.g especially for some sync-send cases).

The typical approach to what you are asking about is that your
application code track the things being sent and track confirmation of
their delivery, such that your application itself knows what it needs
to send upon the reconnect to be sure it was delivered
(at-least-once), or also originally if something is not accepted
because of e.g disk full problems.

On Wed, 10 Jan 2024 at 16:34, Mario García Pérez  wrote:
>
> Hi,
>
> Sometimes, when trying to send a message to a broker it cannot be send
> correctly due to high disk usage on broker's machine, so message is lost.
>
> To face it I thought 2 different options:
> 1) Use sync parameter in send() call to wait for broker confirmation
> 2) To, asynchronously, take control of messages that have not been
> confirmed and try to resend them.
>
> As option 1 entail to process get blocked until broker confirm the
> reception of the message, my choice is option 2. However, I don't know how
> get the list of messages whose reception was not confirmed by broker.
> Analyzing class Sender I find the method getUnsettled() that return the
> number of unsettled messages, but nothing that return the list of messages.
>
> Also, I have read that if connection fails, after reconnect, the unsettled
> messages will be retransmitted, so I suspect that the retrieve of unsettled
> messages could be possible.
>
> So, in conclussion, my questions are:
> Is possible to get the list of unsettled messages? If possible, how I can
> get it?
>
> Thank you in advance.

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