> We export queue size (artemis.persistent.size) per queue via metrics for monitoring purposes – I assume it is sum of all pending messages on a given queue (journal + paging + large-messages). Is this correct?
Essentially, yes. This metric is kind of a glorified message count that indicates how much data you would receive if you consumed every message on the queue. > Is it correct to assume that total messages which are in ../data/journal folder and expected to be loaded into memory on subsequent startup is restricted by global-max-size param in heap. Yes, but it is controlled at write time rather than at read time. To elaborate, the global-max-size param controls how much message data the broker keeps in memory (and therefore writes to the journal) before applying the corresponding address-full-policy. In this way the journal should never exceed the configured size. Then when the journal is read the contents are restored to memory. The global-max-size is not enforced when then journal is read, only when it is written. > Is there a guideline for the initialDelaySeconds that we should set for liveness probe in K8s? There's no strict guideline here since the behavior will depend on how fast your disk is and how much data is in the journal. The recommendation would be to benchmark reloading a "full" journal and tune the liveness probe accordingly. Of course, you'll need to ensure consistent disk/network performance to avoid unnecessary restarts or wait times. Hope that helps! Justin On Tue, Jan 6, 2026 at 9:59 AM Shiv Kumar Dixit < [email protected]> wrote: > Thanks Justin for details. > > > > 1. So basically, broker only loads previously active messages (from > ../data/journal) in memory on subsequent startups. > 2. Messages paged to disk are loaded (from ../data/paging) when > previous queues are empty, and consumers demand more. > 3. We export queue size (artemis.persistent.size) per queue via > metrics for monitoring purposes – I assume it is sum of all pending > messages on a given queue (journal + paging + large-messages). Is this > correct? > 4. Is it correct to assume that total messages which are in > ../data/journal folder and expected to be loaded into memory on subsequent > startup is restricted by global-max-size param in heap. E.g. if my max heap > is 6 GB and global-max-size is set to 1.2 GB then broker can hold max 1.2 > GB of messages in memory (loaded via ../data/journal) and rest pending > messages will be paged. > 5. When we deploy broker in K8s, it also needs a liveness probe to > indicate broker has started successfully. It means by this time all > required messages etc. should be loaded from journal. Is there a guideline > for the initialDelaySeconds that we should set for liveness probe in K8s? > If it is too early then broker startup is not done fully and we risk > restarts. If it is too late, we wait unnecessary for the first check to be > triggered. > > > > Best Regards > > Shiv > > > > *From:* Justin Bertram <[email protected]> > *Sent:* 06 January 2026 08:14 PM > *To:* [email protected] > *Subject:* Re: Artemis broker startup and pending messages impact > > > > > > *Unverified Sender: *The sender of this email has not been verified. > Review the content of the message carefully and verify the identity of the > sender before acting on this email: replying, opening attachments or > clicking links. > > > > > When artemis broker starts up, does it need to first load all persistent > messages in memory to be ready for normal broker operations? > > > > Among other things, the broker will parse and load messages persisted to > the journal. However, it won't parse and load messages persisted to paging. > Pages aren't parsed until the queue is empty and more messages are needed. > > > > In general, you can think of the journal as an up-to-date snapshot of what > is in the heap. It includes address & queue definitions, messages, > transaction meta-data, duplicate ID caches, etc. > > > > > if we stop broker with viz. 4 GB of persistent pending messages, does it > need min 4 GB of free memory at startup to load these messages? > > > > If you stop the broker with 4GB of persistent pending messages then after > you restart the broker and reload the messages you'll have that same 4GB of > persistent pending messages. > > > > > If it uses heap memory for this work or non-heap memory is used for this? > > > > It uses heap. > > > > I think I answered #3 in the answer to #1 above. > > > > > If a message is of 10KB, does broker need exact 10KB to store the > messages in memory and disk? Or additional space is needed for metadata or > encoding etc.? > > > > There's always some additional space required for metadata, etc. > > > > > > Justin > > > > On Tue, Jan 6, 2026 at 5:09 AM Shiv Kumar Dixit < > [email protected]> wrote: > > We are hosting Artemis broker in Kubernetes using operator-based solution. > We deploy the broker as statefulset with 2 or 4 replicas. We assign for > e.g. 6 GB for heap and 9 GB for pod, 1.2 GB (1/5 of max heap) for > global-max-size. All addresses normally use -1 for max-size-bytes but some > less frequently used queues are defined with 100KB for max-size-bytes to > allow early paging. > > We need some information or documentation link to address following > queries. > > > > 1. When artemis broker starts up, does it need to first load all > persistent messages in memory to be ready for normal broker operations? > E.g. if we stop broker with viz. 4 GB of persistent pending messages, does > it need min 4 GB of free memory at startup to load these messages? > 2. If it uses heap memory for this work or non-heap memory is used for > this? > 3. If we have defined global-max-size of 1.2 GB and address-full-policy is > PAGE and broker has 4 GB of persistent pending messages, will broker first > load 1.2 GB of messages in memory from all addresses for faster delivery > and rest messages will remains on disk? Or first all messages must be > loaded in memory and then paging starts afterwards by keeping 1.2 GB in > memory and pushing rest to disk again? > 4. If a message is of 10KB, does broker need exact 10KB to store the > messages in memory and disk? Or additional space is needed for metadata or > encoding etc.? > > > > > > Best Regards, > > Shiv > > > >
