Initial results from reducing proton-c coding effort

I've now checked in my work to reduce some of the known coding overhead in proton-c. There were 3 parts to this: 1. Stop generating nulls at the end of described lists - if they are not there the decoder must assume they are null - defualt values. 2. Generate nulls instead of default values

Re: WARNING: proton ruby package and gem name change

Whilst the recommendation is clearly not what is being used, how much of an issue is this? It doesnt seem to be a hard requirement for example. I wonder if the disruption caused from changing it after ~6 years and dealing with any resulting confusion actually outweighs the benefits of it being as

WARNING: proton ruby package and gem name change

The proton ruby gem and package are incorrectly named according to the standard gem naming rules, see https://issues.apache.org/jira/browse/PROTON-1760 for details. The short story is we want to change the name from "qpid_proton" to "qpid-proton" for the next release (0.22, not the 0.21 release

[ANNOUNCE] Apache Qpid JMS 0.30.0 released

The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 0.30.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org), based around the

Re: Initial results from reducing proton-c coding effort

These are good improvements. Proton-j is doing most of this already. PROTON-1780 is perhaps more complicated than it seems however. One of the things proton-j always did is try to encode the smallest list/map types it could, and a lot of the time it was notably slower because of the time spent

Re: Initial results from reducing proton-c coding effort

Good work. These changes will be a great candidate to test with qpid-interop to make sure that it still works with the other implementations. And if not then why not. - Original Message - > From: "Andrew Stitcher" > To: "Qpid Users" > Sent:

Re: Broker-j - Restoring BDB Backup

Hi Brian, The steps for restoring of BDB virtual host node store are correct. Though, please be aware that in case of moving node into a different machine you need to reset the bdb ha group as per [1]. As for BDBBackup utility provided by Qpid, it works simply by acquiring locks on je files and

[RESULT] [VOTE] Release Apache Qpid Broker-J 7.0.2

There were 4 binding +1 votes, and no other votes received. The vote has passed. The voting thread can be found here: https://lists.apache.org/thread.html/19d8a355d54be1e28dad288bb5f1079452a62f6963b2e7a74a0b56ab@%3Cusers.qpid.apache.org%3E I will add the archives to the dist release repo and

Re: [VOTE] Release Apache Qpid Broker-J 7.0.2

On 27 February 2018 at 14:57, Oleksandr Rudyy wrote: > Hi all, > > I built a release candidate for a Qpid Broker-J 7.0.2. > Please give it a test out and vote accordingly. > > The source and binary archives can be grabbed from: >

Re: [VOTE] Release Apache Qpid Proton 0.21.0

On 28 February 2018 at 19:33, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton 0.21.0 release, please > give it a test out and vote accordingly. > > The source archive can be grabbed from: >

Re: Memory Leak

Hi Niklas, the client you are using is very old (the final release was about 3 ago I think), and has been replaced by the new Qpid JMS client ( https://qpid.apache.org/components/jms/index.html) - I would strongly advise migrating your ode to use the new client. Having said that I'm not aware of

Re: [VOTE] Release Apache Qpid Proton 0.21.0

+1 * Verified sha512 * Build/install on fedora 27 * Pass self tests * Build/install with current qpid-dispatch master * Pass self tests - Original Message - > From: "Robbie Gemmell" > To: users@qpid.apache.org > Sent: Wednesday, February 28, 2018 2:33:29 PM >

Broker-j - Restoring BDB Backup

I'm planning on using the broker-j provided org.apache.qpid.server.store.berkeleydb.BDBBackup class to backup our HA BDB database. I want to make sure I understand the restore process. To restore the DB for the Virtual Host Node the backup was taken for do we simply: 1. Stop the VirtualHostNode