If you don't close the AMQP connection, then the connection
remains open and the next time when the messages are sent on
the listening topic, then some of the messages will not be processed
as there is no dispatcher running to process the message.
Closes-Bug: #1335086
Change-Id: I1f39eedf1500b6b6209ae0222f32e08e304895e0
In _safe_log it uses recursive closure. The gc can not free stack for
this recursive closure for cycle-reference. So cut down the cycle
to fix it.
Resolved-bug: #1365892
Change-Id: I05fbd7091b886344d76b172a5ad66d9225599d69
Remove intersphinx from the docs build as it triggers network calls that
occasionally fail, and we don't really use intersphinx (links other
sphinx documents out on the internet)
This also removes the requirement for internet access during docs build.
This causes docs jobs to fail because we error out on warnings.
Change-Id: I71e941e2a639641a662a163c682eb86d51de42fb
Related-Bug: #1368910
The ZmqListener constructor only accepts a driver as an argument.
Drop surplus 'None' in listen_for_notifications method.
Change-Id: I6aec91122bb9406e387728eb2a2380f2c2094595
Closes-Bug: #1368154
zmq: Send message to correct endpoint for directed messages
If set the zmq driver needs to use the topic.server
attribute to ensure that messages directed to a
specific endpoint are sent to the correct server rather
than being randomly sent to endpoints advertising the
required topic.
Change-Id: If63235640e0b8e6ec8690a4edaefa1b303705ac6
Closes-bug: #1301723
This change ensures that the amqp1 will be present into the
configfile even the required python module are not present and
also put them into the correct section, [oslo_messaging_amqp1].
Change-Id: I1005405d7ed51090495688eadbe400dbff7c3cc9
This instruction to set up a move in six for the mox module conflicts
with the one in oslotest. We are trying to use mox3 everywhere, so
remove this instruction and let oslotest handle it.
Imported from the incubator change with the same ID.
Change-Id: I59d5799283233f8411044ddb15c8abfc8850014c
The key driver interfaces are implemented in the ProtonDriver class in
driver.py. The logic for interfacing with Pyngus in order to
send/receive messages, manage AMQP connections and links, and handle
protocol events is in controller.py. eventloop.py is a fairly generic
socket connection and I/O processor which runs in its own thread.
controller.py uses the eventloop.py thread to schedule subscription
and message send requests from the driver, as well as handle all
protocol event callbacks coming from Pyngus.
Included in this patch are a set of functional tests that can be run
under tox (tox -eamqp1). These tests fully exercise the new driver,
from the driver API down to the 'wire' - nothing in the driver is
mocked out. The functional tests implement a simple loopback test
broker, which allows the driver to send and receive messages via the
local network. All RPC call patterns, RPC timeouts, and even broker
failover are verified by the included functional tests.
This driver uses the Pyngus module, which is a pure-python client API
built on the Proton AMQP 1.0 protocol engine library from the Apache
Qpid project. Pyngus is available via pypi.python.org.
This driver introduces a dependency on the Proton AMQP 1.0 protocol
library, which is a platform-dependent library that must be installed
in order to use this driver and run the functional tests.
Change-Id: I871703e4cdc04cee3e6c214e911c9df464ede2ed
Implements: blueprint amqp10-driver-implementation
Follow oslo.config conventions for consistency of help strings:
* Use sentence style capitalization.
* End entry with a "."
Fix capitalization of AMQP.
Change-Id: I0a6b170a2a7cfa539e06781f4495c4353d22e4d0
