This adds an optional call_monitor_timeout parameter to the RPC client,
which if specified, will enable heartbeating of long-running calls by
the server. This enables the user to increase the regular timeout to
a much larger value, allowing calls to take a very long time, but
with heartbeating to indicate that they are still running on the server
side. If the server stops heartbeating, then the call_monitor_timeout
takes over and we fail with the usual MessagingTimeout instead of waiting
for the longer overall timeout to expire.
Change-Id: I60334aaf019f177a984583528b71d00859d31f84
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
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
1.As mentioned in [1], we should avoid using six.iteritems to achieve iterators.
We can use dict.items instead, as it will return iterators in PY3 as well.
And dict.items/keys will more readable. 2.In py2, the performance about
list should be negligible, see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
Change-Id: Ia235afc3532f62f265f91ca46d2306c72fc2a2a2
Rework the inline documentation for executors, RPC servers and
clients, notifiers and notification listeners for clarity and flow.
Change-Id: If4f1db853a7fc85340177fd2c9c43a479d72459d
The patch fixes some problems arised after merging the previous
patch which this patch depends on.
Change-Id: If38edec19f9bffc8ac54818b2536243a9edaf7e8
Depends-On: I608c828123b196099933d16801f8ce7d9dd3a079
Closes-Bug: #1584889
This patch fixes the bug in the RPCClient class when a client's
version_cap is set, but target.version is unset. The code does not
check this case, which results in unhandled exceptions.
Change-Id: I623c14b74b9101bb4ab199dff6609fab44388c4a
Closes-Bug: 1574615
The RPCClient class is fully based on the _CallContext class.
I think it is redundant to have the same attributes in the RPCClient
as in the _CallContext just in order to pass instances with these
attributes to the _CallContext._prepare method (which is not so obious
because it can work with both _CallContext and RPCCLient classes,
though these classes are not in the same class hierarchy).
This patch tries to solve all these issues by including both classes
in a hierarchy and to make a little optimization by eliminating
dummy _CallContext instances creation on each cast/call in RPCClient.
Change-Id: I608c828123b196099933d16801f8ce7d9dd3a079
Raise an exception if a caller passes a something for the
version that cannot be parsed as a version.
Change-Id: I167849b1bc6c4d946de42c6459b3577a361e9606
Related-Bug: #1467087
This change adjusts the exception message to be more in line with the
version compatibility algorithm so as to accurately portray the
problem to the log recipient.
The RPCVersionCapError message can be grossly incorrect when the
requested message's major version is lower than the specified version
cap's major version, declaring the requested message version as too
high, when the real error is that the major versions differ (as major
versions are assumed to be incompatible).
Example:
RPCVersionCapError: Requested message version, 3.23 is too
high. It needs to be lower than the specified version cap 4.0.
Change-Id: Iceef999ed385f2ba77449c568127f50f83d47196
Closes-Bug: 1468525
Move the public API out of oslo.messaging to oslo_messaging. Retain
the ability to import from the old namespace package for backwards
compatibility for this release cycle.
bp/drop-namespace-packages
Co-authored-by: Mehdi Abaakouk <mehdi.abaakouk@enovance.com>
Change-Id: Ia562010c152a214f1c0fed767c82022c7c2c52e7