1"use strict";(self.webpackChunkrabbitmq_website=self.webpackChunkrabbitmq_website||[]).push([["16347"],{88029(e,n,s){s.r(n),s.d(n,{metadata:()=>i,default:()=>d,frontMatter:()=>a,contentTitle:()=>o,toc:()=>c,assets:()=>l});var i=JSON.parse('{"id":"queues","title":"Queues","description":"\x3c!--","source":"@site/docs/queues.md","sourceDirName":".","slug":"/queues","permalink":"/docs/next/queues","draft":false,"unlisted":false,"editUrl":"https://github.com/rabbitmq/rabbitmq-website/tree/main/docs/queues.md","tags":[],"version":"current","frontMatter":{"title":"Queues","displayed_sidebar":"docsSidebar"},"sidebar":"docsSidebar","previous":{"title":"Negative Acknowledgements","permalink":"/docs/next/nack"},"next":{"title":"Quorum Queues","permalink":"/docs/next/quorum-queues/"}}'),r=s(74848),t=s(28453);let a={title:"Queues",displayed_sidebar:"docsSidebar"},o="Queues",l={},c=[{value:"What is a Queue?",id:"what-is-a-queue",level:2},{value:"Queue Names",id:"names",level:2},{value:"Server-named Queues",id:"server-named-queues",level:3},{value:"Queue Properties",id:"properties",level:2},{value:"Declaration and Property Equivalence",id:"property-equivalence",level:3},{value:"Optional Arguments",id:"optional-arguments",level:3},{value:"Optional Arguments and Policy-Defined Key Precedence",id:"optional-arguments-precedence",level:3},{value:"Message ordering",id:"message-ordering",level:2},{value:"When messages can be reordered",id:"when-messages-can-be-reordered",level:3},{value:"Preserving message order",id:"preserving-message-order",level:3},{value:"<strong>1.) Use a stream</strong>",id:"1-use-a-stream",level:4},{value:"<strong>2.) Use a queue with a single active consumer</strong>",id:"2-use-a-queue-with-a-single-active-consumer",level:4},{value:"Durability",id:"durability",level:2},{value:"How to Choose",id:"how-to-choose",level:3},{value:"Temporary Queues",id:"temporary-queues",level:2},{value:"Exclusive (Client Connection-Specific) Queues",id:"exclusive-queues",level:2},{value:"Replicated and Distributed Queues",id:"distributed",level:2},{value:"Non-Replicated Queues and Client Operations",id:"transparent-operation-routing",level:2},{value:"Time-to-Live and Length Limit",id:"ttl-and-limits",level:2},{value:"In Durable and In-Memory Storage",id:"storage",level:2},{value:"Priorities",id:"priorities",level:2},{value:"CPU Utilisation and Parallelism Considerations",id:"runtime-characteristics",level:2},{value:"Metrics and Monitoring",id:"metrics",level:2},{value:"Consumers and Acknowledgements",id:"consumer-acknowledgement",level:2},{value:"Prefetch and Consumer Overload",id:"prefetch-consumer-overload",level:3},{value:"Message States",id:"message-states",level:3},{value:"Determining Queue Length",id:"queue-length",level:2},{value:"Avoid Temporary Queues with Well-Known Names",id:"shared-temporary-queues",level:2}];function u(e){let n={a:"a",admonition:"admonition",code:"code",em:"em",h1:"h1",h2:"h2",h3:"h3",h4:"h4",header:"header",li:"li",ol:"ol",p:"p",pre:"pre",strong:"strong",ul:"ul",...(0,t.R)(),...e.components};return(0,r.jsxs)(r.Fragment,{children:[(0,r.jsx)(n.header,{children:(0,r.jsx)(n.h1,{id:"queues",children:"Queues"})}),"\n",(0,r.jsx)(n.h2,{id:"what-is-a-queue",children:"What is a Queue?"}),"\n",(0,r.jsxs)(n.p,{children:["A queue in RabbitMQ is an ordered collection of messages. Messages are enqueued and dequeued (delivered to consumers) in a (",(0,r.jsx)(n.a,{href:"https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)",children:'FIFO ("first in, first out")'})," manner."]}),"\n",(0,r.jsxs)(n.p,{children:["To define a ",(0,r.jsx)(n.a,{href:"https://en.wikipedia.org/wiki/Queue_(abstract_data_type)",children:"queue"})," in generic terms, it is a sequential data structure with two primary operations: an item can be ",(0,r.jsx)(n.strong,{children:"enqueued"})," (added) at the tail and ",(0,r.jsx)(n.strong,{children:"dequeued"})," (consumed) from the head."]}),"\n",(0,r.jsxs)(n.p,{children:["Queues play a major role in the messaging technology space. Many messaging protocols and tools assume that ",(0,r.jsx)(n.a,{href:"./publishers",children:"publishers"})," and ",(0,r.jsx)(n.a,{href:"./consumers",children:"consumers"})," communicate using a queue-like storage mechanism."]}),"\n",(0,r.jsxs)(n.p,{children:["Many features in a messaging system are related to queues. Some RabbitMQ queue features such as priorities and ",(0,r.jsx)(n.a,{href:"./confirms",children:"requeueing"})," by consumers can affect the ordering as observed by consumers."]}),"\n",(0,r.jsx)(n.p,{children:"The information in this topic includes an overview of queues in RabbitMQ and also links out to other topics so you can learn more about using queues in RabbitMQ."}),"\n",(0,r.jsx)(n.admonition,{type:"info",children:(0,r.jsxs)(n.p,{children:["In addition to queues, modern RabbitMQ versions supp
1ort two alternative data structures\ncalled ",(0,r.jsx)(n.a,{href:"./streams",children:"streams and super streams"}),"."]})}),"\n",(0,r.jsxs)(n.p,{children:["This guide primarily covers queues in the context of the ",(0,r.jsx)(n.a,{href:"/tutorials/amqp-concepts",children:"AMQP 0-9-1"})," protocol, however, much of the content is applicable to other supported protocols."]}),"\n",(0,r.jsx)(n.p,{children:"Some protocols (for example: STOMP and MQTT) are based around the idea of topics.\nFor these protocols, queues act as a data accumulation buffer for consumers.\nHowever, it is still important to understand the role queues play\nbecause many features still operate at the queue level, even for those protocols."}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"./streams",children:"Streams"})," is an alternative messaging data structure available in RabbitMQ. Streams provide different features from queues."]}),"\n",(0,r.jsx)(n.p,{children:"The information about RabbitMQ queues covered in this topic includes:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#names",children:"Queue Names"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#properties",children:"Queue Properties"})}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#message-ordering",children:"Message Ordering"})," in a queue"]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#durability",children:"Queue Durability"})," and how it relates to message persistence"]}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#distributed",children:"Replicated Queue Types"})}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#transparent-operation-routing",children:"Transparent Operation Routing"})," for clients"]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#temporary-queues",children:"Temporary"})," and ",(0,r.jsx)(n.a,{href:"#exclusive-queues",children:"exclusive"})," queues"]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#runtime-characteristics",children:"Runtime Resource"})," usage by queue replicas"]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#optional-arguments",children:"Optional Queue Arguments"}),' ("x-arguments")']}),"\n",(0,r.jsxs)(n.li,{children:["Declaration and ",(0,r.jsx)(n.a,{href:"#property-equivalence",children:"Property Equivalence"})]}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#metrics",children:"Queue Metrics"})}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.a,{href:"#ttl-and-limits",children:"TTL"})," and length limits"]}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#priorities",children:"Priority Queues"})}),"\n"]}),"\n",(0,r.jsxs)(n.p,{children:["For topics related to consumers, see the ",(0,r.jsx)(n.a,{href:"./consumers",children:"Consumers guide"}),".\n",(0,r.jsx)(n.a,{href:"./classic-queues",children:"Classic queues"}),", ",(0,r.jsx)(n.a,{href:"./quorum-queues",children:"quorum queues"}),"\nand ",(0,r.jsx)(n.a,{href:"./streams",children:"streams"})," also have dedicated guides."]}),"\n",(0,r.jsx)(n.h2,{id:"names",children:"Queue Names"}),"\n",(0,r.jsx)(n.p,{children:"Queues have names so that applications can reference them."}),"\n",(0,r.jsxs)(n.p,{children:["Applications may pick queue names or ask the broker to ",(0,r.jsx)(n.a,{href:"#server-named-queues",children:"generate a name"}),"\nfor them. Queue names may be up to 255 bytes of UTF-8 characters."]}),"\n",(0,r.jsxs)(n.p,{children:['Queue names starting with "amq." are reserved for internal\nuse by the broker. Attempts to declare a queue with a name that\nviolates this rule will result in a ',(0,r.jsx)(n.a,{href:"./channels",children:"channel-level exception"}),"\nwith reply code 403 (",(0,r.jsx)("code",{children:"ACCESS_REFUSED"}),")."]}),"\n",(0,r.jsx)(n.h3,{id:"server-named-queues",children:"Server-named Queues"}),"\n",(0,r.jsx)(n.p,{children:"In AMQP 0-9-1, the broker can generate a unique queue name on behalf of\nan app. To use this feature, pass an empty string as the queue name\nargument: the same generated name may be obtained by subsequent\nmethods in the same channel by using the empty string where a queue\nname is expected. This works because the channel remembers the last\nserver-generated queue name."}),"\n",(0,r.jsxs)(n.p,{children:["Server-named queues are meant to be used for state that is transient\nin nature and specific to a particular consumer (application instance).\nApplications can share such names in message metadata to let other applications respond\nto them (as demonstrated in ",(0,r.jsx)(n.a,{href:"/tutorials",children:"tutorial six"}),").\nOtherwise, the names of server-named queues should be known and used only by the\ndeclaring application instance. The instance should also set up appropriate\nbindings (routing) for the queue, so that publishers can use well-known\n",(0,r.jsx)(n.a,{href:"./exchanges",children:"exchanges"})," instead of the server-generated queue name directly."]}),"\n",(0,r.jsx)(n.h2,{id:"properties",children:"Queue Properties"}),"\n",(0,r.jsx)(n.p,{children:"Queues have properties that define how they behave. There is a set\nof mandatory properties and a map of optional ones:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:"Name"}),"\n",(0,r.jsx)(n.li,{children:"Durable (the queue will survive a broker restart)"}),"\n",(0,r.jsx)(n.li,{children:"Exclusive (used by only one connection and the queue will be deleted when that connection closes)"}),"\n",(0,r.jsx)(n.li,{children:"Auto-delete (queue that has had at least one consumer is deleted when last consumer unsubscribes)"}),"\n",(0,r.jsx)(n.li,{children:"Arguments (optional; used by plugins and broker-specific features such as message TTL, queue length limit, etc)"}),"\n"]}),"\n",(0,r.jsxs)(n.admonition,{type:"important",children:[(0,r.jsxs)(n.p,{children:["Note that ",(0,r.jsx)(n.strong,{children:"not all property combination make sense"}),". For example,\nexclusive queues should almost always be ",(0,r.jsx)(n.a,{href:"#server-named-queues",children:"server-named"}),"."]}),(0,r.jsx)(n.p,{children:"Such queues are supposed to be used for client-specific or connection (session)-specific data."})]}),"\n",(0,r.jsx)(n.p,{children:"When exclusive queues use well-known (static) names, in case of client disconnection\nand immediate reconnection there will be a natural race condition between RabbitMQ nodes\nthat will delete such queues and recovering clients that will try to re-declare them.\nThis can result in client-side connection recovery failure or exceptions, and create unnecessary confusion\nor affect application availability."}),"\n",(0,r.jsx)(n.h3,{id:"property-equivalence",children:"Declaration and Property Equivalence"}),"\n",(0,r.jsx)(n.admonition,{type:"tip",children:(0,r.jsx)(n.p,{children:"Specifically for the queue type property, the property equivalence\ncheck can be relaxed. Alternatively, a default queue type (DQT) can be configured."})}
1),"\n",(0,r.jsxs)(n.p,{children:["Before a queue can be used it has to be declared. Declaring\na queue will cause it to be created if it does not already\nexist. The declaration will have no effect if the queue does\nalready exist and its attributes are the same as those in the\ndeclaration. When the existing queue attributes are not the\nsame as those in the declaration a channel-level exception\nwith code 406 (",(0,r.jsx)("code",{children:"PRECONDITION_FAILED"}),") will be raised."]}),"\n",(0,r.jsx)(n.p,{children:"Specifically for the queue type property, the property equivalence\nchecks can be relaxed or configured to use a default."}),"\n",(0,r.jsxs)(n.p,{children:["See the ",(0,r.jsx)(n.a,{href:"./vhosts#default-queue-type",children:"Virtual Hosts guide"})," to learn more."]}),"\n",(0,r.jsx)(n.h3,{id:"optional-arguments",children:"Optional Arguments"}),"\n",(0,r.jsx)(n.p,{children:'Optional queue arguments, also known as "x-arguments" because of their\nfield name in the AMQP 0-9-1 protocol, is a map (dictionary) of arbitrary key/value\npairs that can be provided by clients when a queue is declared.'}),"\n",(0,r.jsx)(n.p,{children:"The map is used by various features and plugins such as"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsxs)(n.li,{children:["Queue type (e.g. ",(0,r.jsx)(n.a,{href:"./quorum-queues",children:"quorum"})," or ",(0,r.jsx)(n.a,{href:"./classic-queues",children:"classic"}),")"]}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"./ttl",children:"Message and queue TTL"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"./maxlength",children:"Queue length limit"})}),"\n",(0,r.jsxs)(n.li,{children:["Quorum queue ",(0,r.jsx)(n.a,{href:"./quorum-queues#poison-message-handling",children:"redelivery limit"})]}),"\n",(0,r.jsxs)(n.li,{children:["Max number of ",(0,r.jsx)(n.a,{href:"./priority",children:"priorities"})," of a classic queue"]}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"and so on."}),"\n",(0,r.jsx)(n.p,{children:"The same idea is also used with other protocol operations, for example, when\nregistering a consumer:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"./consumer-priority",children:"Consumer priorities"})}),"\n"]}),"\n",(0,r.jsxs)(n.p,{children:["Some optional arguments are set at queue declaration time and remain immutable over the entire\nlifetime of the queue. Others can be dynamically changed after queue declaration via ",(0,r.jsx)(n.a,{href:"./policies",children:"policies"}),"."]}),"\n",(0,r.jsx)(n.admonition,{type:"tip",children:(0,r.jsxs)(n.p,{children:["For keys that can be set via ",(0,r.jsx)(n.a,{href:"./policies",children:"policies"}),", always first\nconsider using a policy instead of setting these values in application code"]})}),"\n",(0,r.jsxs)(n.p,{children:["For example, ",(0,r.jsx)(n.a,{href:"./quorum-queues",children:"queue type"})," (",(0,r.jsx)(n.code,{children:"x-queue-type"}),") and max number\nof ",(0,r.jsx)(n.a,{href:"./priority",children:"queue priorities"})," (",(0,r.jsx)(n.code,{children:"x-max-priority"}),") must be set at queue declaration time\nand cannot be changed after that."]}),"\n",(0,r.jsx)(n.p,{children:"Optional queue arguments can be set differently:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsxs)(n.li,{children:["To groups of queues using ",(0,r.jsx)(n.a,{href:"./policies",children:"policies"})," (recommended)"]}),"\n",(0,r.jsx)(n.li,{children:"On a per-queue basis when a queue is declared by a client"}),"\n",(0,r.jsxs)(n.li,{children:["For the ",(0,r.jsx)(n.code,{children:"x-queue-type"})," argument, ",(0,r.jsx)(n.a,{href:"./vhosts#default-queue-type",children:"using a default queue type"})]}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"The former option is more flexible, non-intrusive, does not require application\nmodifications and redeployments. Therefore it is highly recommended for most users.\nNote that some optional arguments such as queue type or max number of priorities can\nonly be provided by clients because they cannot be dynamically changed and must be known\nat declaration time."}),"\n",(0,r.jsxs)(n.p,{children:["The way optional arguments are provided by clients varies from client library\nto client library but is usually an argument next to the ",(0,r.jsx)("code",{children:"durable"}),",\n",(0,r.jsx)("code",{children:"auto_delete"})," and other arguments of the function (method) that\ndeclares queues."]}),"\n",(0,r.jsx)(n.h3,{id:"optional-arguments-precedence",children:"Optional Arguments and Policy-Defined Key Precedence"}),"\n",(0,r.jsxs)(n.p,{children:["When the same key is provided by both client-provided ",(0,r.jsx)(n.code,{children:"x-arguments"})," and by a ",(0,r.jsx)(n.a,{href:"./policies",children:"policy"}),",\nthe former take precedence."]}),"\n",(0,r.jsxs)(n.p,{children:["However, if an ",(0,r.jsx)(n.a,{href:"./policies#operator-policies",children:"operator policy"})," is also used, that will take precedence over the client-provided\narguments, too. Operator policies are a protection mechanism and override client-provided values\nand user policy values."]}),"\n",(0,r.jsxs)(n.p,{children:["For numerical values such as ",(0,r.jsx)(n.a,{href:"./maxlength",children:"maximum queue length"})," or ",(0,r.jsx)(n.a,{href:"./ttl",children:"TTL"}),",\nthe lower value of the two will be used. If an application needs or chooses to use a lower value,\nthat will be allowed by an operator policy. A value higher than that defined in the operator policy,\nhowever, cannot be used."]}),"\n",(0,r.jsx)(n.p,{children:"Use operator policies to introduce guardrails for application-controlled parameters related\nto resource use (e.g. peak disk space usage)."}),"\n",(0,r.jsx)(n.h2,{id:"message-ordering",children:"Message ordering"}),"\n",(0,r.jsx)(n.p,{children:"Message ordering matters when there are causal dependencies between messages.\nRabbitMQ tries to preserve the order of messages."}),"\n",(0,r.jsxs)(n.p,{children:["A queue is an ordered collection of messages providing ",(0,r.jsx)(n.a,{href:"https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)",children:"FIFO"})," semantics.\nWhen publishing on a single ",(0,r.jsx)(n.a,{href:"./channels",children:"channel"}),", messages are enqueued in publishing order in every queue they are routed to.\nWhen publishing happens on multiple connections or channels, their sequences of messages will be routed concurrently and interleaved.\nDelivery from a queue to consumers proceeds in enqueue order (unless below events occur)."]}),"\n",(0,r.jsx)(n.h3,{id:"when-messages-can-be-reordered",children:"When messages can be reordered"}),"\n",(0,r.jsx)(n.p,{children:"Even if RabbitMQ aims to preserve order, the following will change effective delivery order:"}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsxs)(n.li,{children:[(0,r.jsxs)(n.strong,{children:["Message ",(0,r.jsx)(n.a,{href:"./priority",children:"priorities"})]}),":\nhigher-priority messages may be delivered before lower-priority messages."]}),"\n",(0,r.jsxs)(n.li,{children:[(0,r.jsx)(n.strong,{children:"Multiple active consumers on the same queue"}),":\nthe broker still dequeues in FIFO, but any redelivery can change order.\nRedelivery happens when consumers ",(0,r.jsx)(n.a,{href:"./confirms#consumer-nacks-requeue",children:"negatively acknowledge"})," with requeue or a channel/session closes with unacked messages.\nRedelivered messages are flagged (AMQP 1.0: ",(0,r.jsx)(n.code,{children:"first-acquirer=false"}),", AMQP 0-9-1: ",(0,r.jsx)(n.code,{children:"redelivered=true"}),")."]}),"\n"]}),"\n",(0,r.jsx)(n.h3,{id:"preserving-message-order",children:"Preserving message order"}),"\n",(0,r.jsx)(n.p,{children:"To preserve message order in RabbitMQ you have two options."}),"\n",(0,r.jsx)(n.h4,{id:"1-use-a-stream",children:(0,r.jsxs)(n.strong,{children:["1.) Use a ",(0,r.jsx)(n.a,{href:"./stream
1s",children:"stream"})]})}),"\n",(0,r.jsx)(n.p,{children:"A stream is an immutable append-only log. Each message gets its offset assigned at publish-time. This offset never changes."}),"\n",(0,r.jsxs)(n.p,{children:["Multiple consumers can process messages from the same stream concurrently without affecting ordering.\nWith ",(0,r.jsx)(n.a,{href:"./stream-filtering",children:"stream filtering"}),", you can split work so that different consumers process disjoint subsets of the stream while preserving order within each subset."]}),"\n",(0,r.jsx)(n.h4,{id:"2-use-a-queue-with-a-single-active-consumer",children:(0,r.jsx)(n.strong,{children:"2.) Use a queue with a single active consumer"})}),"\n",(0,r.jsx)(n.p,{children:"To keep order with queues:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsxs)(n.li,{children:["Enable ",(0,r.jsx)(n.a,{href:"./consumers#single-active-consumer",children:"Single Active Consumer"})," so only one consumer receives messages at a time.\n(Alternatively, run one consumer per queue.)"]}),"\n",(0,r.jsx)(n.li,{children:"If your consumers return messages to the queue, make sure they return those messages in the order they received them."}),"\n",(0,r.jsxs)(n.li,{children:["For quorum queues, set a ",(0,r.jsx)(n.a,{href:"./quorum-queues#poison-message-handling",children:"delivery limit"}),".\nThis ensures messages are requeued at the front of the queue."]}),"\n",(0,r.jsxs)(n.li,{children:["AMQP 0-9-1: don\u2019t use ",(0,r.jsx)(n.code,{children:"basic.get"}),". When stopping a consumer, prefer closing the ",(0,r.jsx)(n.a,{href:"./channels",children:"channel"})," over ",(0,r.jsx)(n.code,{children:"basic.cancel"}),"."]}),"\n",(0,r.jsxs)(n.li,{children:["If you need to process messages concurrently while preserving order for each domain entity (e.g. per order ID), you can use the\n",(0,r.jsxs)(n.a,{href:"./modulus-hash-exchange",children:[(0,r.jsx)(n.code,{children:"x-modulus-hash"})," exchange"]})," to partition messages across multiple queues, each with a single active consumer."]}),"\n"]}),"\n",(0,r.jsx)(n.h2,{id:"durability",children:"Durability"}),"\n",(0,r.jsxs)(n.p,{children:["Queues can be durable or transient (non-durable). Metadata of a durable queue is stored on disk,\nwhile metadata of a transient queue is stored in memory when possible.\nThe same distinction is made for ",(0,r.jsx)(n.a,{href:"./publishers#message-properties",children:"messages at publishing time"}),"\nin some protocols, e.g. AMQP 0-9-1 and MQTT."]}),"\n",(0,r.jsxs)(n.p,{children:["In environments and use cases where durability is important, applications\nmust use durable queues ",(0,r.jsx)(n.em,{children:"and"})," make sure that ",(0,r.jsx)(n.a,{href:"/docs/publishers",children:"publishers"})," mark published messages as persisted."]}),"\n",(0,r.jsxs)(n.p,{children:["Durable queues will be recovered on node boot, including messages in them published as persistent.\nMessages published as transient will be ",(0,r.jsx)(n.strong,{children:"discarded"})," during recovery, even if they were stored\nin durable queues."]}),"\n",(0,r.jsx)(n.p,{children:"Transient queues will be deleted on node boot. They therefore will not survive a node restart,\nby design. Messages in transient queues will also be discarded."}),"\n",(0,r.jsxs)(n.admonition,{type:"warning",children:[(0,r.jsxs)(n.p,{children:["Transient (non-durable) non-exclusive classic queues are ",(0,r.jsx)(n.a,{href:"/release-information/deprecated-features-list/",children:"deprecated"}),"\nand cannot be declared by default starting with RabbitMQ ",(0,r.jsx)(n.code,{children:"4.3.0"}),"."]}),(0,r.jsx)(n.p,{children:"Please use one of the following:"}),(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#durability",children:"durable queues"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#exclusive-queues",children:"non-durable exclusive queues"})}),"\n",(0,r.jsxs)(n.li,{children:["durable queues ",(0,r.jsx)(n.a,{href:"./ttl#queue-ttl",children:"with a queue TTL"})," (a reasonably close equivalent to non-exclusive transient queues)"]}),"\n"]}),(0,r.jsxs)(n.p,{children:["To explicitly allow transient non-exclusive queues, add the following\nline to ",(0,r.jsx)(n.code,{children:"rabbitmq.conf"}),":"]}),(0,r.jsx)(n.pre,{children:(0,r.jsx)(n.code,{className:"language-ini",children:"# Enables deprecated non-durable (transient) non-exclusive queues\n# (disabled by default as of RabbitMQ `4.3.0`, will be removed in a later version)\ndeprecated_features.permit.transient_nonexcl_queues = true\n"})})]}),"\n",(0,r.jsx)(n.h3,{id:"how-to-choose",children:"How to Choose"}),"\n",(0,r.jsxs)(n.p,{children:["In most other cases, durable queues are the recommended option. For ",(0,r.jsx)(n.a,{href:"#distributed",children:"replicated queues"}),",\nthe only reasonable option is to use durable queues."]}),"\n",(0,r.jsxs)(n.p,{children:["Throughput and latency of a queue is ",(0,r.jsx)(n.strong,{children:"not affected"})," by whether a queue is durable or not\nin most cases. Only environments with very high queue or binding churn \u2014 that is, where queues are deleted\nand re-declared hundreds or more times a second \u2014 will see latency improvements for\nsome operations, namely on bindings. The choice between durable and transient queues\ntherefore comes down to the semantics of the use case."]}),"\n",(0,r.jsx)(n.p,{children:"Temporary queues can be a reasonable choice for workloads with transient clients, for example,\ntemporary WebSocket connections in user interfaces, mobile applications and devices\nthat are expected to go offline or use switch identities. Such clients usually have\ninherently transient state that should be replaced when the client reconnects."}),"\n",(0,r.jsxs)(n.p,{children:["Some queue types do not support transient queues. ",(0,r.jsx)(n.a,{href:"./quorum-queues",children:"Quorum queues"})," must\nbe durable due to the assumptions and requirements of the underlying replication protocol,\nfor example."]}),"\n",(0,r.jsx)(n.h2,{id:"temporary-queues",children:"Temporary Queues"}),"\n",(0,r.jsx)(n.p,{children:"With some workloads queues are supposed to be short lived. While clients can\ndelete the queues they declare before disconnection, this is not always convenient.\nOn top of that, client connections can fail, potentially leaving unused\nresources (queues) behind."}),"\n",(0,r.jsx)(n.p,{children:"RabbitMQ supports a number of queue properties that make sense for the data that is\ntransient or client-specific in nature. Some of these settings can be applied to\ndurable queues but not every combination makes sense."}),"\n",(0,r.jsx)(n.admonition,{type:"tip",children:(0,r.jsxs)(n.p,{children:["Consider using ",(0,r.jsx)(n.a,{href:"#names",children:"server-generated names"})," for exclusive temporary queues. Since such queues\nare not meant to be shared between N consumers, using unique names makes sense."]})}),"\n",(0,r.jsx)(n.p,{children:"There are three ways to make queue deleted automatically:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:"Exclusive queues (covered below)"}),"\n",(0,r.jsx)(n.li,{children:"TTLs (also covered below)"}),"\n",(0,r.jsx)(n.li,{children:"Auto-delete queues"}),"\n"]}),"\n",(0,r.jsxs)(n.p,{children:["An auto-delete queue will be deleted when its last consumer\nis cancelled (e.g. using the ",(0,r.jsx)("code",{children:"basic.cancel"})," in AMQP 0-9-1)\nor gone (closed channel or connection, or lost TCP connection with the server)."]}),"\n",(0,r.jsxs)(n.p,{children:["If a queue never had any consumers, for instance, when all consumption happens\n",(0,r.jsx)(n.a,{href:"/docs/consumers#polling",children:"using polling"}),", it won't be automatically\ndeleted. For such cases, use exclusive queues or queue TTL."]}),"\n",(0,r.jsxs)(n.admonition,{type:"warning",children:[(0,r.jsxs)(n.p,{children:["Transient (non-durable) non-exclusive classic queues are ",(0,r.jsx)(n.a,{href:"/release-information/deprecated-features-list/",children:"deprecated"}),"\nand cannot be declared by default starting with RabbitMQ ",(0,r.jsx)(n.code,{children:"4.3.0"}),"."]}),(0,r.jsx)(n.p,{children:"Please use one of the following:"}),(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#durability",children:"durable queues"})}),"\n",(0,r.jsx)(n.li,{children:(0,r.jsx)(n.a,{href:"#exclusive-queues",children:"non-durable exclusive queues"})}),"\n",(0,r.jsxs)(n.li,{children:["durable queues ",(0,r.jsx)(n.a,{href:"./ttl#queue-ttl",children:"with a queue TTL"})," (a reasonably close equivalent to non-exclusive transient queues)"]}),"\n"]}),(0,r.jsxs)(n.p,{children:["To explicitly allow transient non-exclusive queues, add the following\nline to ",(0,r.jsx)(n.code,{children:"rabbitmq.conf"}),":"]}),(0,r.jsx)(n.pre,{children:(0,r.jsx)(n.code,{className:"language-ini",children:"# Enables deprecated non-durable (transient) non-exclusive queues\n# (disabled by default as of RabbitMQ `4.3.0`, will be removed in a later version)\ndeprecated_features.permit.transient_nonexcl_queues = true\n"})}),(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"/docs/ttl#queue-ttl",children:"Queue TTL"})," can be used for cleanup of unused durable queues."]}),(0,r.jsx)(n.p,{children:"When RabbitMQ detects a non-durable and non-exclusive queue, it will display a deprecation\nwarning in the management UI."})]}),"\n",(0,r.jsx)(n.h2,{id:"exclusive-queues",children:"Exclusive (Client Connection-Specific) Queues"}),"\n",(0,r.jsxs)(n.p,{children:["An exclusive queue can only be used (consumed from, purged, deleted, etc)\nby its declaring connection. Such queues are by definition ",(0,r.jsx)(n.a,{href:"#temporary-queues",children:"temporary"})," in nature,\nsetting the ",(0,r.jsx)(n.code,{children:"exclusive"})," property on a durable queue does not make logical sense\nsince such queue c
1annot outlive its declaring connection, and thus cannot satisfy its durability\nproperty in case of a node restart."]}),"\n",(0,r.jsxs)(n.p,{children:["Queues declared as exclusive will always be declared as classic queues: exclusive ",(0,r.jsx)(n.a,{href:"./quorum-queues",children:"quorum queues"}),"\nand ",(0,r.jsx)(n.a,{href:"./streams",children:"streams"})," do not make logical sense as their lifetimes would be bound to the lifetime\nof a specific client connection and thus a single node (or application instance)."]}),"\n",(0,r.jsx)(n.admonition,{type:"tip",children:(0,r.jsxs)(n.p,{children:["Consider using ",(0,r.jsx)(n.a,{href:"#names",children:"server-generated names"})," for exclusive queues. Since such queues\ncannot be shared between N consumers, using server-generated names makes most sense."]})}),"\n",(0,r.jsxs)(n.p,{children:["An attempt to use an exclusive queue from\na different connection will result in a channel-level exception\n",(0,r.jsx)("code",{children:"RESOURCE_LOCKED"})," with an error message that says\n",(0,r.jsx)("code",{children:"cannot obtain exclusive access to locked queue"}),"."]}),"\n",(0,r.jsx)(n.p,{children:"Exclusive queues are deleted when their declaring connection is closed\nor gone (e.g. due to underlying TCP connection loss). They therefore\nare only suitable for client-specific transient state."}),"\n",(0,r.jsx)(n.p,{children:"It is common to make exclusive queues server-named."}),"\n",(0,r.jsxs)(n.p,{children:['Exclusive queues are declared on the "client-local" node (the node that the client declaring\nthe queue is connected to), regardless of the ',(0,r.jsx)(n.code,{children:"queue_leader_locator"})," value."]}),"\n",(0,r.jsx)(n.h2,{id:"distributed",children:"Replicated and Distributed Queues"}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"./quorum-queues",children:"Quorum queues"})," is replicated, data safety and consistency-oriented queue type.\nClassic queues historically supported replication but this feature was ",(0,r.jsx)(n.strong,{children:"removed"})," for RabbitMQ 4.x."]}),"\n",(0,r.jsxs)(n.p,{children:["Any client ",(0,r.jsx)(n.a,{href:"./connections",children:"connection"})," can use any queue, whether it is replicated or not,\nregardless of the node the queue replica is hosted on or the node the client is connected to.\nRabbitMQ will route the operations to the appropriate node transparently for clients."]}),"\n",(0,r.jsx)(n.p,{children:"For example, in a cluster with nodes A, B and C, a client connected to node A can consume\nfrom a queue Q hosted on B, while a client connected to node C can publish in a way that routes\nmessages to queue Q."}),"\n",(0,r.jsxs)(n.p,{children:["Client libraries or applications ",(0,r.jsx)(n.strong,{children:"may"})," choose to connect to the node that hosts the current leader replica of a specific queue\nfor improved data locality."]}),"\n",(0,r.jsxs)(n.p,{children:["This general rule applies to all messaging data types supported by RabbitMQ except for one.\n",(0,r.jsx)(n.a,{href:"./streams",children:"Streams"})," are an exception to this rule, and require clients, regardless of the protocol they use, to connect to a node\nthat hosts a replica (a leader of rollower) of the target stream.\nConsequently, RabbitMQ Stream protocol clients will ",(0,r.jsx)(n.a,{href:"./stream-connections",children:"connect to multiple nodes in parallel"}),"."]}),"\n",(0,r.jsxs)(n.p,{children:["Queues can also be ",(0,r.jsx)(n.a,{href:"./federated-queues",children:"federated"}),"\nacross loosely coupled nodes or clusters."]}),"\n",(0,r.jsx)(n.p,{children:"Note that intra-cluster replication and federation\nare orthogonal features and should not be considered direct alternatives."}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"./streams",children:"Streams"})," is another replicated data structure supported by RabbitMQ, with a different\nset of supported operations and features."]}),"\n",(0,r.jsx)(n.h2,{id:"transparent-operation-routing",children:"Non-Replicated Queues and Client Operations"}),"\n",(0,r.jsxs)(n.p,{children:["Any client ",(0,r.jsx)(n.a,{href:"./connections",children:"connection"})," can use any queue, including non-replicated (single replica) queues,\nregardless of the node the queue replica is hosted on or the node the client is connected to.\nRabbitMQ will route the operations to the appropriate node transparently for clients."]}),"\n",(0,r.jsx)(n.p,{children:"For example, in a cluster with nodes A, B and C, a client connected to node A can consume\nfrom a queue Q hosted on B, while a client connected to node C can publish in a way that routes\nmessages to queue Q."}),"\n",(0,r.jsxs)(n.p,{children:["Client libraries or applications ",(0,r.jsx)(n.strong,{children:"may"})," choose to connect to the node that hosts the current leader replica of a specific queue\nfor improved data locality."]}),"\n",(0,r.jsxs)(n.p,{children:["This general rule applies to all messaging data types supported by RabbitMQ except for one.\n",(0,r.jsx)(n.a,{href:"./stream
1s",children:"Streams"})," are an exception to this rule, and require clients, regardless of the protocol they use, to connect to a node\nthat hosts a replica (a leader of rollower) of the target stream.\nConsequently, RabbitMQ Stream protocol clients will ",(0,r.jsx)(n.a,{href:"./stream-connections",children:"connect to multiple nodes in parallel"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"ttl-and-limits",children:"Time-to-Live and Length Limit"}),"\n",(0,r.jsxs)(n.p,{children:["Queues can have their length ",(0,r.jsx)(n.a,{href:"./maxlength",children:"limited"}),".\nQueues and messages can have a ",(0,r.jsx)(n.a,{href:"./ttl",children:"TTL"}),"."]}),"\n",(0,r.jsx)(n.p,{children:"Both features can be used for data expiration and as a way of limiting\nhow many resources (RAM, disk space) a queue can use at most, e.g.\nwhen consumers go offline or their throughput falls behind publishers."}),"\n",(0,r.jsx)(n.h2,{id:"storage",children:"In Durable and In-Memory Storage"}),"\n",(0,r.jsx)(n.p,{children:"In modern RabbitMQ versions, quorum queues and classic queues v2 alike actively move data to disk and only keep a relatively\nsmall working set in memory."}),"\n",(0,r.jsx)(n.p,{children:"In some protocols (e.g. AMQP 0-9-1) clients can publish messages as persistent or transient. Transient\nmessages will still be stored on disk but will be discarded during the next node restart."}),"\n",(0,r.jsxs)(n.p,{children:["In AMQP 0-9-1, this is done\nvia a message property (",(0,r.jsx)("code",{children:"delivery_mode"})," or, in some clients, ",(0,r.jsx)("code",{children:"persistent"}),")."]}),"\n",(0,r.jsxs)(n.p,{children:["Other relevant guides on the topic are ",(0,r.jsx)(n.a,{href:"./quorum-queues#resource-use",children:"Quorum Queues"}),", ",(0,r.jsx)(n.a,{href:"./streams#feature-comparison",children:"Streams"}),",\n",(0,r.jsx)(n.a,{href:"./memory-use",children:"Reasoning About Memory Usage"}),", ",(0,r.jsx)(n.a,{href:"./alarms",children:"Alarms"}),", ",(0,r.jsx)(n.a,{href:"./memory",children:"Memory Alarms"}),", ",(0,r.jsx)(n.a,{href:"./disk-alarms",children:"Free Disk Space Alarms"}),",\n",(0,r.jsx)(n.a,{href:"./production-checklist",children:"Deployment Guidelines"}),", and ",(0,r.jsx)(n.a,{href:"./persistence-conf",children:"Message Store Configuration"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"priorities",children:"Priorities"}),"\n",(0,r.jsxs)(n.p,{children:["Queues can have 0 or more ",(0,r.jsx)(n.a,{href:"./priority",children:"priorities"}),". This feature is opt-in:\nonly queues that have maximum number of priorities configured via an optional argument\n(see above) will do prioritisation."]}),"\n",(0,r.jsxs)(n.p,{children:["Publishers specify message priority using the ",(0,r.jsx)("code",{children:"priority"})," field\nin message properties."]}),"\n",(0,r.jsx)(n.p,{children:"If priority queues are desired, we recommend using between 1 and 10.\nCurrently using more priorities will consume more resources (Erlang processes)."}),"\n",(0,r.jsx)(n.h2,{id:"runtime-characteristics",children:"CPU Utilisation and Parallelism Considerations"}),"\n",(0,r.jsx)(n.p,{children:"Currently a single queue replica (whether leader or follower) is limited to a single CPU core\non its hot code path. This design therefore assumes that most systems\nuse multiple queues in practice."}),"\n",(0,r.jsx)(n.admonition,{type:"danger",children:(0,r.jsx)(n.p,{children:"A single queue is generally considered to be an anti-pattern, and not just for resource utilisation\nreasons."})}),"\n",(0,r.jsxs)(n.p,{children:["For workloads that push queue throughput to the limits, consider using ",(0,r.jsx)(n.a,{href:"./streams",children:"streams or partitioned streams"}),"\nwith a ",(0,r.jsx)(n.a,{href:"/client-libraries/devtools",children:"RabbitMQ Stream Protocol client"}),"."]}),"\n",(0,r.jsx)(n.h2,{id:"metrics",children:"Metrics and Monitoring"}),"\n",(0,r.jsxs)(n.p,{children:["RabbitMQ collects multiple metrics about queues. Most of them are available\nvia ",(0,r.jsx)(n.a,{href:"./management",children:"RabbitMQ HTTP API and management UI"}),", which is designed for monitoring.\nThis includes queue length, ingress and egress rates, number of consumers, number of\nmessages in various states (e.g. ready for delivery or ",(0,r.jsx)(n.a,{href:"./confirms",children:"unacknowledged"}),"),\nnumber of messages in RAM vs. on disk, and so on."]}),"\n",(0,r.jsxs)(n.p,{children:[(0,r.jsx)(n.a,{href:"./man/rabbitmqctl.8",children:"rabbitmqctl"}
1)," can list queues and some basic metrics."]}),"\n",(0,r.jsxs)(n.p,{children:["Runtime metrics such as VM scheduler usage, queue (Erlang) process GC activity, amount of\nRAM used by the queue process, queue process mailbox length can be accessed\nusing the ",(0,r.jsx)(n.a,{href:"https://github.com/rabbitmq/rabbitmq-server/tree/main/deps/rabbitmq_top",children:"rabbitmq-top"})," plugin and\nindividual queue pages in the management UI."]}),"\n",(0,r.jsx)(n.h2,{id:"consumer-acknowledgement",children:"Consumers and Acknowledgements"}),"\n",(0,r.jsxs)(n.p,{children:["Messages can be consumed by registering a consumer (subscription),\nwhich means RabbitMQ will push messages to the client, or fetched\nindividually for protocols that support this (e.g. the ",(0,r.jsx)("code",{children:"basic.get"})," AMQP 0-9-1 method),\nsimilarly to HTTP GET."]}),"\n",(0,r.jsxs)(n.p,{children:["Delivered messages can be ",(0,r.jsx)(n.a,{href:"./confirms",children:"acknowledged by consumer"})," explicitly\nor automatically as soon as a delivery is written to connection socket."]}),"\n",(0,r.jsxs)(n.p,{children:["Automatic acknowledgement mode generally will provide higher throughput\nrate and uses less network bandwidth. However, it offers the least number\nof guarantees when it comes to ",(0,r.jsx)(n.a,{href:"./reliability",children:"failures"}),". As a rule of\nthumb, consider using manual acknowledgement mode first."]}),"\n",(0,r.jsx)(n.h3,{id:"prefetch-consumer-overload",children:"Prefetch and Consumer Overload"}),"\n",(0,r.jsx)(n.p,{children:"Automatic acknowledgement mode can also overwhelm\nconsumers which cannot process messages as quickly as they are delivered.\nThis can result in permanently growing memory usage and/or\nOS swapping for the consumer process."}),"\n",(0,r.jsxs)(n.p,{children:["Manual acknowledgement mode provides a way to ",(0,r.jsx)(n.a,{href:"./confirms",children:"set a limit on the number\nof outstanding (unconfirmed) deliveries"}),": channel QoS (prefetch)."]}),"\n",(0,r.jsx)(n.p,{children:"Consumers using higher (several thousands or more) prefetch levels can experience\nthe same overload problem as consumers using automatic acknowledgements."}),"\n",(0,r.jsx)(n.p,{children:"High number of unacknowledged messages will lead to higher memory usage by\nthe broker."}),"\n",(0,r.jsx)(n.h3,{id:"message-states",children:"Message States"}),"\n",(0,r.jsx)(n.p,{children:"Enqueued messages therefore can be in one of two states:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:"Ready for delivery"}),"\n",(0,r.jsxs)(n.li,{children:["Delivered but not yet ",(0,r.jsx)(n.a,{href:"./confirms",children:"acknowledged by consumer"})]}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"Message breakdown by state can be found in the management UI."}),"\n",(0,r.jsx)(n.h2,{id:"queue-length",children:"Determining Queue Length"}),"\n",(0,r.jsx)(n.p,{children:"It is possible to determine queue length in a number of ways:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsxs)(n.li,{children:["With AMQP 0-9-1, using a property on the ",(0,r.jsx)("code",{children:"queue.declare"})," method response\n(",(0,r.jsx)("code",{children:"queue.declare-ok"}),"). The field name is ",(0,r.jsx)("code",{children:"message_count"}),". How it is accessed\nvaries from client library to client library."]}),"\n",(0,r.jsxs)(n.li,{children:["Using ",(0,r.jsx)(n.a,{href:"./management",children:"RabbitMQ HTTP API"}),"."]}),"\n",(0,r.jsxs)(n.li,{children:["Using the ",(0,r.jsx)(n.a,{href:"./man/rabbitmqctl.8",children:"rabbitmqctl"})," ",(0,r.jsx)("code",{children:"list_queues"})," command."]}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"Queue length is defined as the number of messages ready for delivery."}),"\n",(0,r.jsx)(n.h2,{id:"shared-temporary-queues",children:"Avoid Temporary Queues with Well-Known Names"}),"\n",(0,r.jsxs)(n.p,{children:["A ",(0,r.jsx)(n.a,{href:"#temporary-queues",children:"temporary queue"})," that is not exclusive can be client named and shared\nbetween multiple consumers. This, however, is not recommended and can lead to a race condition\nbetween RabbitMQ node operations and client recovery."]}),"\n",(0,r.jsx)(n.p,{children:"Consider the following scenario:"}),"\n",(0,r.jsxs)(n.ul,{children:["\n",(0,r.jsx)(n.li,{children:"A consumer uses an auto-delete queue with a well-known names"}),"\n",(0,r.jsx)(n.li,{children:"Client's connection fails"}),"\n",(0,r.jsx)(n.li,{children:"Client detects it and initiates connection recovery"}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"As the failed connection which had the only consumer on an auto-delete queue,\nthe queue must be deleted by RabbitMQ. This operation will take some time,\nduring which the consumer may recover."}
1),"\n",(0,r.jsx)(n.p,{children:"Then depending on the timing of operations, the queue can be"}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsx)(n.li,{children:"Declared by the recovering client and then deleted"}),"\n",(0,r.jsx)(n.li,{children:"Deleted and then re-declared"}),"\n"]}),"\n",(0,r.jsx)(n.p,{children:"In the first case, the client will try to re-register its consumer on a queue that's\nbeen concurrently deleted, which will lead to a channel exception."}),"\n",(0,r.jsx)(n.p,{children:"There are two solutions to this fundamental race condition:"}),"\n",(0,r.jsxs)(n.ol,{children:["\n",(0,r.jsx)(n.li,{children:"Introduce a connection recovery delay. For example, several RabbitMQ client libraries\nuse a connection recovery delay of 5 seconds by default"}),"\n",(0,r.jsx)(n.li,{children:"Use server-named queues, which side steps the problem entirely since the new client connection\nwill use a different queue name from its predecessor"}),"\n"]})]})}function d(e={}){let{wrapper:n}={...(0,t.R)(),...e.components};return n?(0,r.jsx)(n,{...e,children:(0,r.jsx)(u,{...e})}):u(e)}},28453(e,n,s){s.d(n,{R:()=>a,x:()=>o});var i=s(96540);let r={},t=i.createContext(r);function a(e){let n=i.useContext(t);return i.useMemo(function(){return"function"==typeof e?e(n):{...n,...e}},[n,e])}function o(e){let n;return n=e.disableParentContext?"function"==typeof e.components?e.components(r):e.components||r:a(e.components),i.createElement(t.Provider,{value:n},e.children)}}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.