Capabilities
What the KubeMQ RabbitMQ (AMQP 0-9-1) connector supports, the caps it negotiates, the methods it rejects, the inert arguments it accepts, and the nine gotchas.
This reference defines exactly what the embedded KubeMQ RabbitMQ (AMQP 0-9-1) connector supports, the capabilities it forces during negotiation, the methods it rejects, and the arguments it accepts but silently ignores. Use it to decide which client features are safe to rely on and which ones will be refused. Every claim here is grounded in the connector source and integration tests.
Supported AMQP methods
The connector implements the AMQP 0-9-1 (RabbitMQ dialect) method set needed for real applications:
| Class | Methods |
|---|---|
| Connection | connection.start / start-ok / tune / tune-ok / open / open-ok / close / close-ok |
| Channel | channel.open / close / flow (replies flow-ok, no-op) |
| Exchange | exchange.declare (incl. passive), exchange.delete |
| Queue | queue.declare (incl. passive, server-named), queue.bind, queue.unbind, queue.purge, queue.delete |
| Basic | basic.publish, basic.consume, basic.cancel, basic.deliver, basic.get, basic.ack, basic.nack, basic.reject, basic.qos, basic.recover (requeue=true), basic.return |
| Confirm | confirm.select (publisher confirms) |
Exchanges and bindings are virtual connector-side routing — every AMQP queue is backed by
a single KubeMQ Queue channel (amqp.{vhost}.{queue}). See
Channel Mapping and
Architecture.
Forced / negotiated capabilities
The connector pins the connection tuning values during connection.tune. A client may request
lower values, but cannot exceed these ceilings:
| Capability | Value |
|---|---|
| ChannelMax | 2047 |
| FrameMax | 131072 (floor 4096) |
| Heartbeat | 60s (final = min non-zero of both sides; 2× idle → client.timeout) |
| MaxBodySize | 104857600 (100 MiB) |
| MaxConnections | 1000 (0 = unlimited) |
| Protocol header | exactly AMQP\x00\x00\x09\x01 (8 bytes); mismatch → echo header + TCP close |
| SASL mechanism | PLAIN only (AMQPLAIN / EXTERNAL → 503) |
See Configuration to tune ChannelMax / FrameMax / Heartbeat / MaxBodySize / MaxConnections.
Not implemented (540)
These methods are advertised as unsupported and always return 540 not-implemented:
tx.*(transactions) — on a confirm-mode channel,tx.selectreturns406instead;exchange.bind/exchange.unbind(exchange-to-exchange bindings);basic.publish(immediate=true);basic.recover-async(andbasic.recover(requeue=false));connection.update-secret;- non-PLAIN SASL (AMQPLAIN / EXTERNAL) →
503.
See Error & Reason Codes for the full close-code table.
Inert arguments (accepted, badged, no effect)
Inert arguments (gotcha #7). These exchange/queue arguments are accepted (and badged in
the dashboard topology view) but never alter behavior. Do not rely on them — a queue
declared with, e.g., x-max-length is not actually enforcing it.
The connector's inertArgNames set — accepted, WARN-logged once, and badged in the topology
view:
alternate-exchange;- priority queues (
x-max-priority) — thepriorityproperty is carried as a tag, but ordering is not honored; x-max-length/x-max-length-bytes/x-overflow;x-queue-type/x-queue-mode;- single-active-consumer (
x-single-active-consumer); x-expires(queue-level TTL);- consumer
x-priority.
Two more inputs are inert but not in the badge set:
x-message-ttl(queue-level TTL) — silently ignored; only the per-messageexpirationproperty drives TTL (gotcha #1 / gotcha #7);prefetch-sizeonbasic.qos— accepted but ignored (onlyprefetch-countis honored).
The nine gotchas
These connector behaviors deviate from RabbitMQ classic. Each is a documented contract, not a bug — most stay invisible until a corner case hits production.
| # | Gotcha | Where documented |
|---|---|---|
| 1 | TTL never dead-letters — expired messages are eager-dropped even with a DLX | Reliability, Migrating from RabbitMQ |
| 2 | DLX rejected-trigger only — only reject/nack(requeue=false) triggers DLX | Reliability |
| 3 | Publisher confirms have no rollback — already-delivered queues stay; retry duplicates | Reliability |
| 4 | basic.get ~1s latency floor — polling is slow; prefer basic.consume | Queues & Consumers |
| 5 | Requeue at tail, not head — fairness differs from RabbitMQ classic | Queues & Consumers |
| 6 | Exclusive queues + direct reply-to are node-local — need LB session affinity | RPC pattern, Migrating from RabbitMQ |
| 7 | Inert queue arguments — priority / max-length / queue-type / etc. accepted but never apply | this page, Exchanges & Routing |
| 8 | Reserved "default" vhost + name charset — ;:*> / whitespace / trailing-. rejected | Channel Mapping, Migrating from RabbitMQ |
| 9 | Publish-then-close loses unconfirmed messages — a fire-and-forget basic.publish then an immediate channel/connection close silently drops still-buffered publishes (≤ 64), with no client error; use a confirm channel before closing | Reliability, Migrating from RabbitMQ |
Related
Channel Mapping
How every AMQP queue maps to amqp.{vhost}.{queue}, the name charset, and property/header mapping.
Error & Reason Codes
The 311–541 close-code table and the triggers behind each rejection above.
Connections & Observability
The dashboard endpoints, metrics, and inert-argument badges that surface these caps.
Migrating from RabbitMQ
The thirteen deviations from RabbitMQ classic and the connection-string swap.
Was this page helpful?
Work Queues
Distribute time-consuming tasks across competing workers over AMQP 0-9-1 — durable queues, manual ack, prefetch, and at-least-once delivery on the KubeMQ Queue.
Channel Mapping
The reference for how a RabbitMQ AMQP 0-9-1 queue maps to a KubeMQ Queue channel — the amqp.{vhost}.{queue} grammar, charset, and property/header mapping.