[openstack-dev] blueprint amqp-rpc-fast-reply-queue
pekowski at gmail.com
Tue Jan 29 17:32:37 UTC 2013
Mark, thanks for the input...
On Tue, Jan 29, 2013 at 9:14 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> In this case, there is a (performance) benefit to using the new feature
> so it probably does make sense to have an off-by-default feature which
> we'd enable by default for the H release.
> The config option should be documented though :)
I'm glad to hear there is a good chance that I can get this approved in a
single release and with a documented config option.
The other contention point is how the RPC msg_id sent in the message data
is used. The (somewhat) short explanation is that if the new
implementation continues to use it as a unique identifier for the message
and the fast option is enabled, a NEW->OLD RPC call will get executed on
the server side, the response will be sent to a queue that will be
immediately deleted (auto-delete), the RPC call will timeout on the caller
side and no meaningful log entry will be produced. There is an alternative
that makes msg_id the name of the response queue with the advantage that a
log entry can be generated on the caller side stating the called failed due
to calling a downlevel service. This case is a user error. The user
enabled the fast option while downlevel services are present.
I now favor the approach of leaving msg_id as the unique identifier of the
message, but just want to be clear of the consequences. I will wait a
while to see if anyone cares and then resubmit the patch for code review
and hope we have reached a consensus.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev