From 0f0fd7299d9d66533700bbe1050432ad638ecde8 Mon Sep 17 00:00:00 2001 From: Shilla Saebi Date: Fri, 14 Mar 2014 01:48:54 -0400 Subject: [PATCH] change to module001-ch008-queues-messaging changed rpc worker and rpc cast sentence changed reply to plural paces around "and" removed "we" revised sentence added space "using " added a space before A added space and capitals after Change-Id: I3f9d5fb147aaacd42e5790aa751547e5821482a7 --- .../module001-ch008-queues-messaging.xml | 68 +++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/training-guides/module001-ch008-queues-messaging.xml b/doc/training-guides/module001-ch008-queues-messaging.xml index c1a2581675..256a763ed3 100644 --- a/doc/training-guides/module001-ch008-queues-messaging.xml +++ b/doc/training-guides/module001-ch008-queues-messaging.xml @@ -64,21 +64,21 @@ Nova RPC Mappings The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single - instance is deployed and shared in an OpenStack cloud. Every Nova - component connects to the message broker and, depending on its + instance is deployed and shared in an OpenStack cloud. Every component + within Nova connects to the message broker and, depending on its personality, such as a compute node or a network node, may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute or Network). Invokers and Workers do not - actually exist in the Nova object model, but we are going to use - them as an abstraction for sake of clarity. An Invoker is a - component that sends messages in the queuing system via two - operations: 1) rpc.call and ii) rpc.cast; a Worker is a component - that receives messages from the queuing system and reply + actually exist in the Nova object model, but in this example they are used + as an abstraction for the sake of clarity. An Invoker is a + component that sends messages in the queuing system using rpc.call + and rpc.cast. A worker is a component + that receives messages from the queuing system and replies accordingly to rcp.call operations. Figure 2 shows the following internal elements: - Topic Publisher:a Topic + Topic Publisher: A Topic Publisher comes to life when an rpc.call or an rpc.cast operation is executed; this object is instantiated and used to push a message to the queuing system. Every publisher connects @@ -86,7 +86,7 @@ limited to the message delivery. - Direct Consumer:a Direct + Direct Consumer: A Direct Consumer comes to life if (an only if) a rpc.call operation is executed; this object is instantiated and used to receive a response message from the queuing system; Every consumer @@ -97,7 +97,7 @@ Topic Publisher (only rpc.call operations). - Topic Consumer:a Topic + Topic Consumer: A Topic Consumer comes to life as soon as a Worker is instantiated and exists throughout its life-cycle; this object is used to receive messages from the queue and it invokes the appropriate @@ -111,7 +111,7 @@ exchange key is ‘topic.host’). - Direct Publisher:a Direct + Direct Publisher: A Direct Publisher comes to life only during rpc.call operations and it is instantiated to return the message required by the request/response operation. The object connects to a @@ -119,7 +119,7 @@ incoming message. - Topic Exchange:The + Topic Exchange: The Exchange is a routing table that exists in the context of a virtual host (the multi-tenancy mechanism provided by Qpid or RabbitMQ); its type (such as topic vs. direct) determines the @@ -127,14 +127,14 @@ topic-based exchange for every topic in Nova. - Direct Exchange:this is a + Direct Exchange: This is a routing table that is created during rpc.call operations; there are many instances of this kind of exchange throughout the life-cycle of a message broker node, one for each rpc.call invoked. - Queue Element:A Queue is + Queue Element: A Queue is a message bucket. Messages are kept in the queue until a Consumer (either Topic or Direct Consumer) connects to the queue and fetch it. Queues can be shared or can be exclusive. @@ -302,56 +302,56 @@ The following parameters are default: - Insist: insist on + Insist: Insist on connecting to a server. In a configuration with multiple load-sharing servers, the Insist option tells the server that the client is insisting on a connection to the specified server. Default is False. - Connect_timeout: the + Connect_timeout: The timeout in seconds before the client gives up connecting to the server. The default is no timeout. - SSL: use SSL to connect + SSL: Use SSL to connect to the server. The default is False. More precisely consumers need the following parameters: - Connection: the above + Connection: The above mentioned Connection object. - Queue:name of the + Queue: Name of the queue. - Exchange:name of the + Exchange: Name of the exchange the queue binds to. - Routing_key:the + Routing_key: The interpretation of the routing key depends on the value of the exchange_type attribute. - Direct exchange:if the + Direct exchange: If the routing key property of the message and the routing_key attribute of the queue are identical, then the message is forwarded to the queue. - Fanout exchange:messages + Fanout exchange: Messages are forwarded to the queues bound the exchange, even if the binding does not have a key. - Topic exchange:if the + Topic exchange: If the routing key property of the message matches the routing key of the key according to a primitive pattern matching scheme, then the message is forwarded to the queue. The message routing key @@ -365,7 +365,7 @@ - Durable:this flag + Durable: This flag determines the durability of both exchanges and queues; durable exchanges and queues remain active when a RabbitMQ server restarts. Non-durable exchanges/queues (transient @@ -374,29 +374,29 @@ bind to transient exchanges. Default is True. - Auto_delete:if set, the + Auto_delete: If set, the exchange is deleted when all queues have finished using it. Default is False. - Exclusive:exclusive + Exclusive: Exclusive queues (such as non-shared) may only be consumed from by the current connection. When exclusive is on, this also implies auto_delete. Default is False. - Exchange_type:AMQP + Exchange_type: AMQP defines several default exchange types (routing algorithms) that covers most of the common messaging use cases. - Auto_ack:acknowledgement + Auto_ack: Acknowledgement is handled automatically once messages are received. By default auto_ack is set to False, and the receiver is required to manually handle acknowledgment. - No_ack:it disable + No_ack: It disables acknowledgement on the server-side. This is different from auto_ack in that acknowledgement is turned off altogether. This functionality increases performance but at the cost of @@ -404,7 +404,7 @@ can deliver them to the application. - Auto_declare:if this is + Auto_declare: If this is True and the exchange name is set, the exchange will be automatically declared at instantiation. Auto declare is on by default. Publishers specify most the parameters of consumers @@ -412,19 +412,19 @@ specify the following: - Delivery_mode:the default + Delivery_mode: The default delivery mode used for messages. The value is an integer. The following delivery modes are supported by RabbitMQ: - 1 or “transient”:the + 1 or “transient”: The message is transient. Which means it is stored in memory only, and is lost if the server dies or restarts. - 2 or “persistent”:the + 2 or “persistent”: The message is persistent. Which means the message is stored both in-memory, and on disk, and therefore preserved if the server dies or restarts.