The introduction to carrot that was here previously has been moved to the introduction page.
Sending/Receiving Messages.
Message consumer.
Parameters: |
|
---|
The routing key (if any). The interpretation of the routing key depends on the value of the exchange_type attribute:
direct exchange
Matches if the routing key property of the message and the routing_key attribute are identical.
fanout exchange
Always matches, even if the binding does not have a key.
topic exchange
Matches the routing key property of the message by a primitive pattern matching scheme. The message routing key then consists of words separated by dots (".", like domain names), and two special characters are available; star ("*") and hash ("#"). The star matches any word, and the hash matches zero or more words. For example "*.stock.#" matches the routing keys "usd.stock" and "eur.stock.db" but not "stock.nasdaq".
AMQP defines four default exchange types (routing algorithms) that covers most of the common messaging use cases. An AMQP broker can also define additional exchange types, so see your message brokers manual for more information about available exchange types.
Direct
Direct match between the routing key in the message, and the routing criteria used when a queue is bound to this exchange.
Topic
Wildcard match between the routing key and the routing pattern specified in the binding. The routing key is treated as zero or more words delimited by "." and supports special wildcard characters. "*" matches a single word and "#" matches zero or more words.
Fanout
Queues are bound to this exchange with no arguments. Hence any message sent to this exchange will be forwarded to all queues bound to this exchange.
Headers
Queues are bound to this exchange with a table of arguments containing headers and values (optional). A special argument named “x-match” determines the matching algorithm, where "all" implies an AND (all pairs must match) and "any" implies OR (at least one pair must match).
- NOTE: carrot has poor support for header exchanges at
this point.
This description of AMQP exchange types was shamelessly stolen from the blog post AMQP in 10 minutes: Part 4 by Rajith Attapattu. Recommended reading.
Raises amqplib.client_0_8.channel.AMQPChannelException: | |
---|---|
if the queue is exclusive and the queue already exists and is owned by another connection. |
Example Usage
>>> consumer = Consumer(connection=DjangoBrokerConnection(),
... queue="foo", exchange="foo", routing_key="foo")
>>> def process_message(message_data, message):
... print("Got message %s: %s" % (
... message.delivery_tag, message_data))
>>> consumer.register_callback(process_message)
>>> consumer.wait() # Go into receive loop
Discard all waiting messages.
Parameter: | filterfunc – A filter function to only discard the messages this filter returns. |
---|---|
Returns: | the number of messages discarded. |
WARNING: All incoming messages will be ignored and not processed.
Example using filter:
>>> def waiting_feeds_only(message):
... try:
... message_data = message.decode()
... except: # Should probably be more specific.
... pass
...
... if message_data.get("type") == "feed":
... return True
... else:
... return False
Receive the next message waiting on the queue.
Returns: | A carrot.backends.base.BaseMessage instance, or None if there’s no messages to be received. |
---|---|
Parameters: |
This method asks the peer to pause or restart the flow of content data.
This is a simple flow-control mechanism that a peer can use to avoid oveflowing its queues or otherwise finding itself receiving more messages than it can process. Note that this method is not intended for window control. The peer that receives a request to stop sending content should finish sending the current content, if any, and then wait until it receives the flow(active=True) restart method.
Iterator processing new messages as they arrive. Every new message will be passed to the callbacks, and the iterator returns True. The iterator is infinite unless the limit argument is specified or someone closes the consumer.
iterconsume() uses transient requests for messages on the server, while iterequeue() uses synchronous access. In most cases you want iterconsume(), but if your environment does not support this behaviour you can resort to using iterqueue() instead.
Also, iterconsume() does not return the message at each step, something which iterqueue() does.
Parameter: | limit – Maximum number of messages to process. |
---|---|
Raises StopIteration: | |
if limit is set and the message limit has been reached. |
Infinite iterator yielding pending messages, by using synchronous direct access to the queue (basic_get).
iterqueue() is used where synchronous functionality is more important than performance. If you can, use iterconsume() instead.
Parameters: |
|
---|---|
Raises StopIteration: | |
If there is no messages waiting, and the iterator is not infinite. |
DEPRECATED Use fetch() like this instead:
>>> message = self.fetch(enable_callbacks=True)
Request specific Quality of Service.
This method requests a specific quality of service. The QoS can be specified for the current channel or for all channels on the connection. The particular properties and semantics of a qos method always depend on the content class semantics. Though the qos method could in principle apply to both peers, it is currently meaningful only for the server.
Parameters: |
|
---|
This method is called when a new message is received by running wait(), process_next() or iterqueue().
When a message is received, it passes the message on to the callbacks listed in the callbacks attribute. You can register callbacks using register_callback().
Parameters: |
|
---|---|
Raises NotImplementedError: | |
If no callbacks has been registered. |
Register a callback function to be triggered by receive().
The callback function must take two arguments:
message_data
The deserialized message data
message
The carrot.backends.base.BaseMessage instance.
Go into consume mode.
Mostly for testing purposes and simple programs, you probably want iterconsume() or iterqueue() instead.
This runs an infinite loop, processing all incoming messages using receive() to apply the message to all registered callbacks.
Receive messages from multiple consumers.
Parameters: |
|
---|
Add consumers from a dictionary configuration:
{
"webshot": {
"exchange": "link_exchange",
"exchange_type": "topic",
"binding_key": "links.webshot",
"default_routing_key": "links.webshot",
},
"retrieve": {
"exchange": "link_exchange",
"exchange_type" = "topic",
"binding_key": "links.*",
"default_routing_key": "links.retrieve",
"auto_delete": True,
# ...
},
}
This method asks the peer to pause or restart the flow of content data.
See Consumer.flow().
Cycle between all consumers in consume mode.
Request specific Quality of Service.
See Consumer.cos().
A combined message publisher and consumer.
Message publisher.
Parameters: |
|
---|
The default delivery mode used for messages. The value is an integer. The following delivery modes are supported by (at least) RabbitMQ:
1
The message is non-persistent. Which means it is stored in memory only, and is lost if the server dies or restarts.
- 2
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.
The default value is 2 (persistent).
If this is True and the exchange name is set, the exchange will be automatically declared at instantiation. You can manually the declare the exchange by using the declare() method.
Auto declare is on by default.
Declare the exchange.
Creates the exchange on the broker.
Send a message.
Parameters: |
|
---|