Consumer in Kafka driver should use only unique topic,
otherwise a FetchDuplicate exception will be raised.
Change-Id: I569ce446eaf05dbc3a7fd0b41a2307e940ab87fb
Closes-bug: #1555081
Currently we trying ot fetch messages from the topics even
they have bot been created yet. This behaviour causes a
KafkaConfigurationError which are raised in the kafka driver.
Change-Id: I78cfd5ac24fbf37be5649232d0bc825319cf6402
Closes-bug: #1557521
In this patch start and stop method is not raised exceptions
if connectivity problem is detected. Rasing exceptions there
exceptions are not expected by MessageHandlerServer.
It hangs server on start
Closes-Bug: #1553168
Change-Id: I891abab2a1184fa65b496ea2f7fc54894bc0b421
In I83a8d09dc0cdae24c12d7043ec810529a9ce57ab, we
made reply and fanout queues expire instead of auto-delete
and set the rabbit_transient_queues_ttl to 10 mins.
In grenade, we seem to see the queues expiring just around
the time the new side is coming up which causes havoc. There
is no reason the rabbit_transient_queues_ttl should not be
higher. So let's bump up the expiry to 30 mins.
Closes-Bug: #1545002
Change-Id: I70a29b762198129fe0a3e904d9f2a7d4242b322c
Now that the bandit linter runs without a bandit.yaml specified,
it should exclude the tests directory similar to how it did before
in the bandit.yaml.
The reason this has not caused a problem yet is because bandit is
still finding a config bandit.yaml in .tox/pep8/etc/bandit/bandit.yaml.
But in a newer version of bandit this will not be the case.
Change-Id: I6cdceaff2aa906e813f1d1e993f60e66358946ee
Add a sleep() to allow other threads (like the one collecting
the stats) to run.
Closes-Bug: #1555632
Change-Id: I6fcb63c10acd76f2815e23fbd303f08974feb993
This patch fixes the problem of sending fanout messages to listeners
located on the same host via the pika transport driver. Only one
listener per host received a fanout message before, because actually
there was only one queue per host, and that queue simply dispatched
incoming messages to listeners in a round robbin manner. In order to
fix this behaviour, every listener is supplied by its own unique
message queue bound to an appropriate fanout exchange now.
Since internal states of pika listeners (or pollers) were changed,
some tests related to pika pollers were also updated properly.
In addition, terms related to sending fanout messages to all_servers
listening some topic are refered to all_workers now (for better
description of what is really going on).
Closes-Bug: #1551661
Change-Id: I5aab6bee8758658fa3fa7e329b54ffa438e85f61
This reverts commit bd81d09c02c5bc8561ad04de91802a5c1917d9e9.
I understand that the change was supposed to fix something, but instead it broke all tests on Python 3!?
It's wrong to replace blindly json.dumps() with jsonutils.dump_as_bytes(). In oslo messaging, the result is usually used as a value in a dictionary, and then the whole dictionary is passed to a second serializer which also serialize to JSON.
Sorry, I don't understand everything, but at least I see that tests passed on py3 before the change, and started to fail with the change.
Maybe json(utils).dumps() is misused in some places, but in this case, you should write a change which only fix these specific places, not replace all calls to dumps().
Change-Id: Icd54ee8e3f5c976dfd50b4b62c7f51288649e112
LOG.warn is deprecated. It still used in a few places.
Updated to non-deprecated LOG.warning.
Change-Id: I124357c259e3cc6c1c8f4cad48c6cb19c1ac2a77
Closes-Bug:#1508442
This patch introduces new parameter --json <file name>.
When it is specified the simulator stores stats in JSON file.
Change-Id: I0b7a87ee614f44baa920569fe0c7046269c90925
Calculate message latency: for RPC calls on both server-side and
on client-side (round-trip); for RPC cast and NOTIFY on server-side
only.
The message is extended with metadata: sequence id, creation time,
reception time and return time (for RPC calls). For every message
the metadata is stored into MessageStatCollector. To reduce memory
consumption the collector aggregates stats on every second and can
print the ongoing stats to stdout. At the finish the overall stats
are printed.
NOTIFY tests are changed to be similar to RPC:
* use pre-generated messages
* parameter "-w WAIT_BEFORE_ANSWER" for processing delay
* parameter "--requeue" to re-queue new messages (only those that
miss the cache)
Change-Id: I4c2fc11bfaee17b6825cdc7d6edf07b8e91ef83a
Avoid any possible references to exc_info tuple by ensuring
we delete it in a finally block, so that even if replying or
logging fails somehow the prior exception is always deleted
correctly.
Change-Id: Id0e5099b9b38b1803bb4514f7cf3deae760d5ac3
This fixes the case where two listeners subscribed to the same topic
fail to reestablish themselves after broker failover. This was due to
a leak where one listener 'overwrote' the other in the driver.
Change-Id: I83822e28c3f15eed639c31891efae222b1ef3de8
Closes-Bug: #1553206
When building packages if git is absent, then we should
fall back to a safe default.
Closes-Bug: #1552251
Change-Id: I9731416117de088282259846d49c2ec3ce09d1dc
Dependency on scipy results in extra requirements to the system
(include the need of Fortran compiler). With this patch the
weighted random choice algorithm is implemented directly.
Change-Id: I60cbc6c452945000add5a65263d1ab4e42dd91f9
Fix a test case that breaks with latest kombu. we mock
the close for the in-memory transport as the newer code
closes connection aggressively (it's doing the right thing)
which ends up with a test failure.
Closes-Bug: #1550630
Change-Id: I8956837a2ecd8ccd858dceac7b99a0f34351603c
Inspired by:
https://bugs.launchpad.net/oslo.messaging/+bug/1508512/comments/1
Add authentication_failure_close capability on the client to
tell the server that it can send us connection.close command
indicating ACCESS_REFUSED as the reasona. If this capability is
absent then authentication failures are reported in the legacy
fashion: by abruptly closing the network connection.
Partial-Bug: #1508512
Change-Id: Icf6108678256e6f922620837c71f8827fe8e8c52
If we specify the default range to pyzmq function,
means default values are the same as pyzmq default values
we fallback to bind-0 system call which is not appropriate
for us as it binds in maximal range > 1024.
https://github.com/zeromq/pyzmq/blob/master/zmq/sugar/socket.py#L212
Change-Id: Idacd99d83c8fb9ad222a7bda187fa67a9b0348da
Closes-Bug: #1550104
