qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith W <keith.w...@gmail.com>
Subject Re: Plans for Qpid Broker J v7.0
Date Wed, 27 Sep 2017 11:34:52 GMT
+users

Hi Adel

I'll be putting something more formal together closer to the release,
but for now a dump of my brain:

For applications using AMQP 0-8..0-10 clients, I would expect no
changes.   For applications using AMQP 1.0 and making use of the Qpid
JMS Client [1] the following would apply:

1) For application using JMS topic subscriptions, the queues backing
topic subscriptions and now named differently.  Messages would need to
be moved manually from the old subscription queues to the new ones to
avoid message loss across the upgrade.
2) Qpid JMS Client 0.24 is required for SCRAM-SHA based SASL
authentication to function.

For the REST API, there are a couple of potentially breaking changes:

1) The biggest change is the modelling of Bindings (the link between
Exchange to Queues).  If you use the REST API to programatically query
or create bindings, the code will need to be changed.
2) The REST API used to return a JSON list in response to a single
object GET request e.g. /api/version/queue/vhn/vh/myqueue.  It now
returns a single JSON object, as one might expect.   It is possible to
get back the old behaviour if desired with a flag.

I'm sure my colleagues will jump in if I have missed anything major.


[1] https://qpid.apache.org/components/jms/index.html

On 27 September 2017 at 10:26, Keith W <keith.wall@gmail.com> wrote:
> Hi Adel
>
> I'll be putting something more formal together closer to the release,
> but for now a dump of my brain:
>
> For applications using AMQP 0-8..0-10 clients, I would expect no
> changes.   For applications using AMQP 1.0 and making use of the Qpid
> JMS Client [1] the following would apply:
>
> 1) For application using JMS topic subscriptions, the queues backing
> topic subscriptions and now named differently.  Messages would need to
> be moved manually from the old subscription queues to the new ones to
> avoid message loss across the upgrade.
> 2) Qpid JMS Client 0.24 is required for SCRAM-SHA based SASL
> authentication to function.
>
> For the REST API, there are a couple of potentially breaking changes:
>
> 1) The biggest change is the modelling of Bindings (the link between
> Exchange to Queues).  If you use the REST API to programatically query
> or create bindings, the code will need to be changed.
> 2) The REST API used to return a JSON list in response to a single
> object GET request e.g. /api/version/queue/vhn/vh/myqueue.  It now
> returns a single JSON object, as one might expect.   It is possible to
> get back the old behaviour if desired with a flag.
>
> I'm sure my colleagues will jump in if I have missed anything major.
>
>
> [1] https://qpid.apache.org/components/jms/index.html
>
>
>
> On 27 September 2017 at 09:05, Adel Boutros <Adelboutros@live.com> wrote:
>> Hello Keith,
>>
>>
>> Normally, with a major release, I could expect some broken APIs when
>> developing code for an older version of the Qpid Broker such as REST API for
>> communicating with the broker or any configuration related disruptive
>> changes.
>>
>>
>> Does the 7.0 version include any disruptive change? Or if I just bump the
>> version of my broker to 7.0 (from 6.0), it will work out of the box?
>>
>>
>> Regards,
>>
>> Adel
>>
>> ________________________________
>> From: Keith W <keith.wall@gmail.com>
>> Sent: Wednesday, September 27, 2017 9:38:15 AM
>> To: users@qpid.apache.org
>> Subject: Plans for Qpid Broker J v7.0
>>
>> Hi all,
>>
>> Qpid Broker J (the Java Broker) is stabilising ready for the next
>> release.   The major user facing changes in this release will be: much
>> improved AMQP 1.0 support, support for JMS 2.0 clients implementing
>> the AMQP 1.0 JMS bind mapping, and much improved message conversion to
>> benefit users with applications using AMQP 1.0 and the older AMQP
>> protocols.  We hope to be putting out an RC in a few weeks time.
>>
>> This anyone has any additional needs, please discuss here.
>>
>> cheers, Keith.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>

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


Mime
View raw message