Consumer callback should look for x-stream-offset header only if
the stream mode is used. Otherwise the message headers attribute could
be None and the error appears when using get method.
Closes-Bug: #2084168
Change-Id: I7f9c742f8f557d9faae2cd749d34dcb15d8005c0
oslo.utils have provided a few useful utility methods to parse or
escape server addresses. Replace the own logic by these methods to
reduce amount of own logic.
Change-Id: I7807314e891e202e47254bf7f98aca4c99005079
This patch fixes the operation of queue_manager in a
containerized environment by adding an additional check
on the start_time in ticks since boot.
This way, we can detect a restart even when the PID remains
unchanged as it is ussual in containers, but the start_time is
different.
[1] https://www.man7.org/linux/man-pages//man5/proc_pid_stat.5.html
From man page above:
(22) starttime %llu
The time the process started after system boot.
Before Linux 2.6, this value was expressed in
jiffies. Since Linux 2.6, the value is expressed
in clock ticks (divide by sysconf(_SC_CLK_TCK)).
Closes-Bug: #2078935
Change-Id: I9e22433ec039ad6783593d9cb7fbe22c9090534e
Add file to the reno documentation build to show release notes for
stable/2024.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.2.
Sem-Ver: feature
Change-Id: Id930bb0fa6313f86eb49040dc3b520950f596eca
With implementation of rabbit_stream_fanout option,
rabbit_transient_queues_ttl is now used to control the size of stream
as well.
While it made sense to re-use the option, it is behaving quite
differently from what is currently described as now it controls not the
queue TTL itself, but messages TTL inside the queue, which is good to
be explicit about.
Change-Id: I78c5066d5d62192f2206893c04823b83791ebdc3
Use more sensible sample default value instead of the program name to
generate the sample config file, so that users can more easily
understand the processname represents a name of the service processes.
Change-Id: Ia97b8d5b6aaa1d54d72945f3abcf4046e39c2bed
This comment references the wrap_socket()
function in the ssl module that is removed
in Python 3.12
Change-Id: I915d5396b0ac62b73246e2e5271109e979f0aab8
The change [1] introduced new logging that
uses INFO loglevel instead of DEBUG with
messages that doesn't help and instead
when there is a lot of messages fills
up the log file.
[1] https://review.opendev.org/c/openstack/oslo.messaging/+/889425
Change-Id: Ide5eb73164632c4e7be8582ba7bc2acde8287c78
The option is strongly related to Eventlet. Eventlet will be removed
and the option have never worked as excepted.
Change-Id: Ide8b22e2c66eae6639266950a39c4042d9a656fd
Typically a simple log will not narrow down the performance, but give
us more information about the service status.
The commit 859e0d4eaa45d75eb822f4a6be46c547187c6358 directly revert
the log due to the msg_id is not accessable for non-rabbit drivers.
It's not the right way to make things better.
So add the log back with the attribute msg_id for base IncomingMessage
class.
Closes-Bug: #2072156
Related-Bug: #1847747
Related-Bug: #1855775
Change-Id: Ib35c8fbb24d5c51d3b54e8ca63e663428318eca5
Catch and handle the NotFound exception when declaring a queue.
This exception occurs when attempting to declare a queue that already
exists and is non-durable, non-HA, and hosted on a node that has
recently gone down.
Closes-Bug: #2068630
Change-Id: I637d931242c64465701266149d5e301f9b5ec4de
These are detected as errors since the clean up was done[1] in
the requirements repository.
[1] 314734e938f107cbd5ebcc7af4d9167c11347406
Change-Id: I323f2d387268950bb00dd25fc762f1f09d012c5e
Whilst working on the Reproducible Builds effort [0], we noticed that
python-oslo.messaging could not be built reproducibly.
This is because the documentation captures the hostname of the build
system.
[0] https://reproducible-builds.org/
This patch uses sample_default from oslo.config to fix this.
Please accept this patch to fix oslo.messaging, magnum, and zaqar
(at least, probably others).
Change-Id: Ie8717e182f709cbddd645a356789e262b47646d3
Description of rabbit_stream_fanout option is incorrect. Actually it
reuses the description of quorum queues. So we need to fix it with a
correct stream queue description.
Closes-Bug: #2058616
Change-Id: I614280c656f7d5fe9043abee93218a9907c395ff
Signed-off-by: frankming <chen27508959@outlook.com>
Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: I6052756356771e89333f17b644fc93dd9326d529
When IPv6 address is used for host, the hostaddr should be formatted
in [<address>]:<port> format instead of <address>:<port> format. This
ensures the correct format is used.
Closes-Bug: 1907702
Change-Id: I6f4a453a69e942d5b2d66ffeca6960b85c8bc721
When waiting for a message in a queue, the queue.get(block=True) prevent
the heartbeats to be sent at correct interval.
So instead of blocking the thread, doing a loop using a StopWatch timer
until the timeout is reached.
Closes-Bug: #2035113
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
Change-Id: Ie5cf5d2bd281508bcd2db1409f18ad96b0822639
When an agent reconnected to a rabbitmq server, it would start
consumming messages from the last offset available in the stream.
This could cause important messages to be lost.
With this patch, oslo_messaging will keep track of the last consummed
offset and restore reading from that point.
Related-bug: #2031497
Change-Id: I449008829b0c0a1a759c211b83f7a99d9c7f2c0d
It would be helpful if "Timed out waiting for <service>" log messages at least
specified on which `reply_q` it was waited for.
Example without the reply_q:
```
12228 2020-09-14 14:56:37.187 7 WARNING nova.conductor.api
[req-1e081db6-808b-4af1-afc1-b87db7839394 - - - - -] Timed out waiting for
nova-conductor. Is it running? Or did this service start before
nova-conductor? Reattempting establishment of nova-conductor connection...:
oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to
message ID 1640e7ef6f314451ba9a75d9ff6136ad
```
Example after adding the reply_q:
```
12228 2020-09-14 14:56:37.187 7 WARNING nova.conductor.api
[req-1e081db6-808b-4af1-afc1-b87db7839394 - - - - -] Timed out waiting for
nova-conductor. Is it running? Or did this service start before
nova-conductor? Reattempting establishment of nova-conductor connection...:
oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply
(reply_2882766a63b540dabaf7d019cf0c0cda)
to message ID 1640e7ef6f314451ba9a75d9ff6136ad
```
It could help us to more merely debug and observe if something went
wrong with a reply queue.
Change-Id: Ied2c881c71930dc631919113adc00112648f9d72
Closes-Bug: #1896925
