1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Release: RabbitMQ 2.6.0
Release Highlights
==================
server
------
bug fixes
- upgrading from RabbitMQ 2.1.1 to any later release could break if
there were durable queues with persistent messages present
- on very slow machines, starting rabbit via the supplied init scripts
could fail with a timeout
- rabbit could fail to stop (when asked to do so) in the presence of
some plug-ins (e.g. shovel)
- 'ram' nodes in a cluster could consume ever increasing amounts of
disk space
- the presence of fast consumers on a queue could significantly delay
the addition of new consumers
- when a client was issuing a tx.commit in one channel, and
simultaneously, in another channel, deleted a durable queue with
persistent messages involved in that tx, rabbit could terminate with
an error
- when a client was using both basic.qos and channel.flow, the latter
would fail to re-enable message flow
- when using 'confirm' mode, the deletion of queues could cause nacks
to be issued (incorrectly)
- in extremely rare circumstances (never observed in the wild), a
queue with a per-queue message ttl could break during sudden changes
in rabbit memory usage
enhancements
- introduce active-active HA, with queues getting mirrored on nodes in
a cluster. See https://www.rabbitmq.com/ha.html
- revamp the handling of AMQP's tx (transaction) class and clarify its
behaviour See https://www.rabbitmq.com/specification.html#tx
- replace the 'administrator' flag, as used by the management plugin,
with a more general 'user tags' mechanism. See
https://www.rabbitmq.com/man/rabbitmqctl.8.man.html#set_user_tags
- do not require 'configure' permissions for passive queue/exchange
declaration
- optimise of message delivery on channels with a basic.qos
prefetch limit that are consuming from many queues
- in 'rabbitmqctl list_channels', do not show the tx mode by default
- when a cluster 'degrades' to only containing ram nodes - through
'rabbitmqctl' actions or node failure - display/log a warning.
- eliminate some spurious errors from the sasl log
java client
-----------
enhancements
- allow response timeouts to be specified in the {Json}RpcClient
- introduce Channel.waitForConfirms() helper method, to make usage of
'confirm' mode more convenient in common cases.
- re-introduce default constructor for BasicProperties
- cater for multiple listeners in all APIs
- eradicate use of impl types in public APIs
- make Tracer embeddable
.net client
-----------
enhancements
- return the complete result of a QueueDeclare, rather than just the
queue name.
- introduce IModel.WaitForConfirms() helper method, to make usage of
'confirm' mode more convenient in common cases.
- document 'confirms' in user guide
management plugin
-----------------
bug fixes
- listing/inspecting queues with exclusive consumers would trigger a
500 error
- lots of cookies would be created for recording implicit preferences
- /api/aliveness-test could return a 500 error instead of 401
- fix off-by-one error in used file descriptor count on some
platforms, and gracefully deal with absence of 'lsof' command
enhancements
- introduce a more advanced permissions model, allowing access to
information for monitoring purposes without the user needing to be a
rabbit administrator. See
https://www.rabbitmq.com/management.html#permissions
- simplify changing the URL; shorter default URL
- make the stats collection interval configurable, providing a way to
reduce the impact of stats collection on servers with many active
connections/channels/queues, and adjust the rate calculation
period. See
https://www.rabbitmq.com/management.html#statistics-interval
- in a cluster, make the management stats db highly available; it
automatically fails over to a different node
- get the management stats db to 'catch up' when it is started in a
cluster and there are existing nodes with queues etc
- report file descriptor counts on more platforms
- display message re-delivery rates
- show (mochi)web listeners
- handle encoding errors gracefully
- add an extension mechanisms - plug-ins for the management
plug-in. The first of these is rabbitmq-shovel-management which
displays status information of the rabbitmq-shovel plugin
- add fields for well-known arguments such as message TTL and alternate
exchange to queue and exchange forms
mochiweb plugin
---------------
bug fixes
- on slow machines a timeout could occur during startup
enhancements
- the '*' listener context no longer needs to be specified, thus
simplifying configuration
auth-backend-ldap plugin
------------------------
enhancements
- eliminate "undefined function" warning on startup
shovel plugin
-------------
enhancements
- support guaranteed delivery with 'confirm' mode
- support the use of AMQP 0-9-1 methods in configuration
STOMP plugin
------------
bug fixes
- heartbeats were issued as a 0x0 byte instead of LF (0x0A)
enhancements
- provide a way to send & subscribe to existing AMQP queues
- support temporary/reply queues
- support durable subscriptions
- set the default prefetch count for /queue destinations to
'unlimited' instead of 1
- optionally allow clients to omit the login & passcode in CONNECT
frames, using a configurable default user instead
- optionally allow clients to omit the CONNECT frame altogether
For more details on all the above see the STOMP plugin documentation
at https://www.rabbitmq.com/stomp.html
federation plugin
-----------------
First release of this plugin, which offers scalable publish /
subscribe messaging across WANs and administrative domains. See
http://hg.rabbitmq.com/rabbitmq-federation/file/default/README
build and packaging
-------------------
bug fixes
enhancements
- make Windows Start menu entries more easily identifiable/searchable
- stop producing the Windows bundle. The Windows installer has matured
sufficiently to take its place.
- employ the same convention for plugin app source files as rebar
- clean up some xref warnings in the plugin build
Upgrading
=========
To upgrade a non-clustered RabbitMQ from release 2.1.1 or later, simply
install the new version. All configuration and persistent message data
is retained.
To upgrade a clustered RabbitMQ from release 2.1.1 or later, install
the new version on all the nodes and follow these instructions:
https://www.rabbitmq.com/clustering.html#upgrading
All configuration and persistent message data is retained.
To upgrade a non-clustered RabbitMQ from release 2.1.0, first upgrade
to 2.1.1 (which retains all data), and then to the current version as
described above.
To upgrade a clustered RabbitMQ prior to 2.1.1 or a stand-alone broker
from releases prior to 2.1.0, if the RabbitMQ installation does not
contain any important data then simply install the new
version. RabbitMQ will move the existing data to a backup location
before creating a fresh, empty database. A warning is recorded in the
logs. If your RabbitMQ installation contains important data then we
recommend you contact rabbitmq-sales@pivotal.io for assistance with the
upgrade.
|
