AMQP 1.0
Most important commands to remember
python3 -m pip show python-qpid-proton— check the installed protocol library.python3 -— run the small send-and-receive example.
Commands and flags
| Command or syntax | Meaning |
|---|---|
python3 -m pip show python-qpid-proton |
Show the installed package; do not install it. |
python3 - <<'PYTHON' |
Read a literal Python script from the following block. |
amqp://localhost:5672 |
Connect to the existing plaintext loopback test broker. |
timeout=5 |
Bound the relevant blocking operation to five seconds. |
credit=1 |
Initially allow one incoming delivery on this receiver link. |
create_sender and create_receiver open links to the lab address. send, receive, and accept perform delivery and acknowledgment. finally closes an established connection even if the example raises an error.
The concepts that matter
1. AMQP defines communication between peers
AMQP 1.0 is a messaging protocol that defines how peers exchange messages and delivery state. A broker can route or store messages between producers and consumers, but the protocol is not one particular broker product.
AMQP 1.0 and AMQP 0-9-1 are different wire protocols. A service advertised as supporting AMQP needs the correct version and configuration for the client. Matching the usual port number is not sufficient.
2. Links have direction and flow control
A connection can contain sessions and directional links. A sender link transfers deliveries to a target; a receiver link receives from a source. The broker’s address model determines how an address maps to a queue or other node.
The receiver grants credit, limiting how many deliveries the sender may initiate on that link. This controls message flow; it is not a byte-size limit, disk-capacity guarantee, or proof that the application processes messages quickly.
3. Settlement communicates delivery responsibility
Delivery outcomes and settlement tell peers how a transfer was handled and when they can stop tracking it. An accepted outcome has meaning at that protocol hop.
A broker accepting a producer’s message does not prove a downstream worker completed the business operation. Likewise, acknowledging before processing can lose work after a crash, while processing before acknowledgment can cause repeated work after redelivery. Applications need deliberate ordering and duplicate handling.
4. Reliability spans more than the wire protocol
Durable storage, queue policy, acknowledgments, retries, and application transactions jointly determine what survives failure. A persistent broker and a nonpersistent message are not automatically the same guarantee as a durable end-to-end workflow.
Even where a protocol offers strong delivery semantics, a payment or database update needs its own correctness boundary. Use message identity and idempotent handling where retries can repeat an operation; do not infer exactly-once business effects from a successful send call.
One small example
Optional: run only against the stated empty dedicated queue. The broker and queue must already exist. Plaintext anonymous access is confined to this local test setup; this is not a remote-service connection recipe.
python3 -m pip show python-qpid-proton
python3 - <<'PYTHON'
from proton import Message
from proton.utils import BlockingConnection
connection = BlockingConnection("amqp://localhost:5672", timeout=5)
try:
receiver = connection.create_receiver("lab-amqp", credit=1)
sender = connection.create_sender("lab-amqp")
sender.send(Message(body="hello-amqp"), timeout=5)
message = receiver.receive(timeout=5)
print(message.body)
receiver.accept()
finally:
connection.close()
PYTHON
The receiver should print hello-amqp, then accept that delivery. This demonstrates one round trip through the queue, not crash recovery or durable storage. A timeout can mean absent routing, missing credit, broker policy, or unavailable delivery; it does not uniquely identify the cause.
The successful receive consumes the test message. If sending succeeds but reception or acceptance fails, a message may remain or be redelivered. Use the lab’s reset procedure before repeating; do not purge a shared queue. No broker is installed or stopped by the script.
Keep this idea: AMQP coordinates message transfer and responsibility; the application must still define when the intended work is complete.