Capabilities

This reference defines exactly what the embedded KubeMQ AMQP 1.0 connector supports, what it rejects, and — critically — what it does not advertise. Use it to decide which client features are safe to rely on and which ones will be refused at attach, transfer, or connection time.

The connector advertises no capabilities

The connector's reply OPEN performative sets only four fields — ContainerID, MaxFrameSize, ChannelMax, and IdleTimeout:

serverOpen := &frames.PerformOpen{
    ContainerID:  "KubeMQ",
    MaxFrameSize: c.maxFrameSize,
    ChannelMax:   c.channelMax,
    IdleTimeout:  advertisedIdle,
}

OfferedCapabilities and DesiredCapabilities are never set on the OPEN reply, and the attach-reply path likewise sets no terminus capabilities. The connector reads a peer's terminus capabilities only to honor a bare-address queue/topic hint — it never echoes or offers capabilities back.

What this means in practice

• Anonymous senders work, but not via ANONYMOUS-RELAY. A client gets anonymous routing by attaching a sender link with a null target address; the connector then routes each transfer by its properties.to. It is null-target-driven, not capability-driven.
• This is the root cause of the Java / Qpid JMS anonymous-terminus limitation. Qpid JMS decides whether to use a single anonymous producer link by checking the peer's offered ANONYMOUS-RELAY capability. Because the connector offers none, Qpid JMS falls back to per-destination sender links and exposes no API to force the raw null-target ATTACH the connector routes on. Native clients (Azure/go-amqp, AMQPNetLite, qpid-proton, fe2o3-amqp, rhea) can open a null-target sender directly and use anonymous routing. See Address Mapping.
• Do not branch your client logic on a negotiated capability — there will be none. Drive behavior from the address (<pattern>/<channel>) and link-properties instead.

Supported features

Rejected / unsupported features

These are non-goals — they are refused deterministically, not silently ignored. Each maps to a wire condition from the error conditions.

Inert / accepted-but-ignored

These are accepted on the wire without error but carry no connector semantics (documented so you do not expect behavior that is not there):

• Message priority — accepted, not honored for ordering.
• group-id / group-sequence — accepted, not used for grouping/ordering.
• footer section — accepted, passed through where applicable, not interpreted.
• OPEN hostname — accepted, ignored (no vhost).
• Idle-timeout from the client — honored by the connector emitting empty frames at half the client's advertised interval, but it is not a feature you negotiate via capabilities.

Limits & forced caps

See Configuration for the CONNECTORS_AMQP10_* knobs behind these caps, and Connections & Observability for the metrics that count limit breaches.

Related