for some reason there are two timeouts. in the batch scenario,
all the time wasted waiting on initial 'get' is never accounted
for so the batch timeout is always longer than it is declared.
Change-Id: I6132c770cccdf0ffad9f178f7463288cf954d672
This is a complicated config opt and the single line help text
doesn't provide anywhere near enough detail for a user to properly
configure it. This change adds the expected format from the
TransportURL docstring and leaves a link to the docs for that
class since the full details are probably too verbose to put in the
help text in their entirety.
Change-Id: I66122bf9c619d35bcb3caadfde9c0dcdb5cd9095
Since RPC and notifications can have different backends, it is
useful to warn users if they use a notification transport in RPC
and vice versa. This patch introduces RPCTransport and
NotificationTransport subclasses of Transport, so it's easier to
add different behavior for them if need be.
Related-Bug: #1680192
Change-Id: Iab60544d69053c8e74c28a2d5c84665be749013f
Probably the most common format for documenting arguments is reST field
lists [1]. This change updates some docstrings to comply with the field
lists syntax.
[1] http://sphinx-doc.org/domains.html#info-field-lists
Change-Id: Ifa8c0db3efc03eac3b034ef642aaa8fce514a66e
If using rabbitmq as rpc backend, oslo.messaging generates large amount
of redundant timeout debug logs (several logs per second on multiple
openstack services, such as nova, heat, cinder), in format of 'Timed out
waiting for RPC response: Timeout while waiting on RPC response - topic:
"<unknown>", RPC method: "<unknown>" info: "<unknown>'. It's because
each socket timeout exception is raised to multiple levels of error
recovery callback functions then logged repeatedly.
However, the accompanying value of socket.timeout exception is currently
always “timed out”. Besides, oslo.messaging has implemented retry
mechanism to recover socket timeout failure. Therefore, IMO those logs
should be suppressed, even if at debug level, to save disk space and
make debugging more convenient.
Change-Id: Iafc360f8d18871cff93e7fd721d793ecdef5f4a1
Closes-Bug: #1714558
Publishing a message using the kombu connection autoretry method may
allow exceptions from the py-amqp library to be raised up to the
application. This does not conform to the documented oslo.messaging
API.
Enhance the try except block to capture any exception and translate it
into a MessageDeliveryFailure.
There are a few cases where exceptions will be raised during autoretry
publishing: recoverable connection or channel errors, and
non-recoverable connection or channel errors.
autoretry will only retry if the error is recoverable. Non recoverable
errors are re-raised immediately regardless of the retry count.
In the case of a recoverable error it seems unlikely that retrying
either the connection or the channel yet again is going to get us
anywhere, so in this case we simply clean up the channel state, log an
error and fail the operation.
In the case of non-recoverable error we are out of luck (think
authentication failure) - further retrying will not help. Best we can
do is clean up state and log the heck out of it.
Change-Id: I2f65d2ee19a8c3e9a323b30404abbf0cbb45a216
Closes-Bug: #1705351
Closes-Bug: #1707160
In testcase, setUp will be called automatically. This patch used
to remove setUp functions that do nothing. Besides, it will keep
code clean.
Change-Id: I2bf79884704974dc00196816f7de43580b474d3e
An endpoint can have an optional 'target' attribute which is used to
filter the callable endpoint by the target.version or .namespace
attributes. Therefore 'target' is reserved and attempting to use an
endpoint that overrides the target attribute (say with a function
call) should fail with a TypeError.
Change-Id: I0bbf9fca0ecbe71efa87c9613ffd32eb718f2c0e
Closes-Bug: #1709131
The FakeExchangeManager uses an instance-level storage for FakeExchanges
mapping[1]. When a client--server pair is created, each keeps their own
instance of FakeDriver -> FakeExchangeManager -> FakeExchange, each of
which has their own (instance-level) copy of e.g _server_queues[2], making
it impossible for them to communicate.
This patch makes the _exchanges mapping a class-level attribute in order
to keep the registered exchanges shared between all Manager instances,
allowing client and server communication (within a single process).
The test_server unit-tests had to be refactored to explicitly pass an exchange
name when building a target. This is required for an exchange name change to
have any effect during a test case run time when compared to passing the
exchange name through the URL. This issue was revealed with this patch.
[1] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_fake.py#L145,#L148
[2] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_fake.py#L88,#L92
Change-Id: I8dff66f4cafeb1f4c57dbfbfaba5d49e50f55fee
Closes-Bug: #1714055
Adds the 'pseudo_vhost' option which when enabled will incorporate the
virtual host into the address semantics. This creates a 'subnet' like
address space for each virtual host. Use this when the messaging bus
does not provide virtual hosting support. It is enabled by default as
to date none of the supported AMQP 1.0 message buses natively support
virtual hosting.
It also updates SSL support: SSL can either use the connection
hostname or the vhost name when validating a server's
certificate. This is controlled by the 'ssl_verify_vhost' option.
This option is disabled by default as it requires both vhost and SNI
support from the server. By default SSL will use the DNS name from
the TransportURL.
Change-Id: I49bb99d1b19e8e7e6fded76198da92ca5f7d65ab
Closes-Bug: #1700835
Partial-Bug: #1706987
This test removes a check of the number of times kombu's
Connection.connect() method is being called for each mocked retry.
The number of calls kombu makes internally is irrelevant to proving
the API is correct. The rest of the tests do ensure that the target
method is retried as expected, which is relevant to the API.
This change is necessary due to the kombu v4.1.0 release actually
calling Connection.connect() twice for each call to the target method
when compaired to earlier releases.
Change-Id: I3326b8e92efe3bef00b1f389d81944af9cc080f8
Closes-Bug: #1707263
We recently move ack/requeue of messages in main/polling thread
of rabbitmq drivers. And break the blocking executor.
This one is not tested by any tests and now deprecated.
This change workaround the issue until we completely remove the
blocking executor.
Change-Id: Id479100f6ff364cf67a199e9b70f9f0c7bf7e1a9
Closes-bug: #1694728
The serializer tests occasionally fail since the order of a dict() is
not guaranteed. Explicitly compute the serializer instead of
pre-computing it.
Change-Id: I74f8fa227e6508491b5982fe7e2841683724540c
Using blocking executor is not recommended for application. But it looks
like some use it just because it's the default and are not aware their
should change it despite of documentation and logging message.
Choosing the application threading model is an important step
of an application.
This change deprecates it, in the future we will just make executor
mandatory. This will ensure that application make a choice.
Also this will reduce headache of oslo.messaging developers to
make the driver code working in a sync and async.
And to finish test coverage of blocking executor is 0%...
This rework some tests to remove logging.captureWarnings() that can
catch unwanted warning of other tests. Tests mocks warning instead.
Related-bug: #694728
Change-Id: Ic67164d12e7a9bed76d6e64ca2ced12e3984ff5f
Be specific regarding which characters can be used in the 'username'
and 'password' fields of the URL.
Change-Id: I9a2a801b3dd86fceffb05f4d52c715748c88d0cb
Closes-Bug: #1693967
The Pika driver was intended to be a more stable and performant
replacement for the default rabbit driver. However due to lack of
both maintainers and compelling evidence that pika is superior to the
existing rabbit driver in either performance or stability it has been
deprecated for removal.
See:
http://lists.openstack.org/pipermail/openstack-dev/2017-May/116679.html
Change-Id: I98e0123edd3248be665325833283689fc3a897f7
In https://review.openstack.org/#/c/436958, we fix a thread safety
issue. But we make the ack/requeue of message asynchronous. In nominal
case, it works, but if network/rabbit connection issue occurs this
can result to rpc call handle twice. By chance we double check already
processed message ids, and drop duplicates, but that if the message
goes to another node, the mitigation won't work.
This restore the previous behavior, to ensure we run application
callback of rpc.call/rpc.cast only when the message have been
successfully ack.
Change-Id: I62b9e09513e3ebfebc64a941d4b21b6c053b511d
The get_rpc_transport wraps get_transport to unify the API in
anticipation of comprehensive separation of RPC and Notification
messaging backends.
Related-Bug: 1680192
Change-Id: Ic6af07b98ff43806c2af38a3ba129991f1e0ec86
Something broke in the way SSL certs are generated. Disable these
tests for now to unblock the gate.
Change-Id: I9764da7995c198597661ecbea27efba9f76e53e3
