mirror of
https://github.com/apache/activemq-artemis.git
synced 2025-02-07 02:29:08 +00:00
3a4b421d2e
Markdown, which is currently used for user-facing documentation, is good for a lot of things. However, it's not great for the kind of complex documentation we have and our need to produce both multi-page HTML and single-page PDF output via Maven. Markdown lacks features which would make the documentation easier to read, easier to navigate, and just look better overall. The current tool-chain uses honkit and a tool called Calibre. Honkit is written in TypeScript and is installed via NPM. Calibre is a native tool so it must be installed via an OS-specific package manager. All this complexity makes building, releasing, uploading, etc. a pain. AsciiDoc is relatively simple like Markdown, but it has more features for presentation and navigation not to mention Java-based Maven tooling to generate both HTML and PDF. Migrating will improve both the appearance of the documentation as well as the processes to generate and upload it. This commit contains the following changes: - Convert all the Markdown for the User Manual, Migration Guide, and Hacking guide to AsciiDoc via kramdown [1]. - Update the `artemis-website` build to use AsciiDoctor Maven tooling. - Update `RELEASING.md` with simplified instructions. - Update Hacking Guide with simplified instructions. - Use AsciiDoc link syntax in Artemis Maven doc plugin. - Drop EPUB & MOBI docs for User Manual as well as PDF for the Hacking Guide. All docs will be HTML only except for the User Manual which will have PDF. - Move all docs up out of their respective "en" directory. This was a hold-over from when we had docs in different languages. - Migration & Hacking Guides are now single-page HTML since they are relatively short. - Refactor README.md to simplify and remove redundant content. Benefits of the change: - Much simplified tooling. No more NPM packages or native tools. - Auto-generated table of contents for every chapter. - Auto-generated anchor links for every sub-section. - Overall more appealing presentation. - All docs will use the ActiveMQ favicon. - No more manual line-wrapping! AsciiDoc recommends one sentence per line and paragraphs are separated by a blank line. - AsciiDoctor plugins for IDEA are quite good. - Resulting HTML is less than *half* of the previous size. All previous links/bookmarks should continue to work. [1] https://github.com/asciidoctor/kramdown-asciidoc
27 lines
2.1 KiB
Plaintext
27 lines
2.1 KiB
Plaintext
= Detecting Slow Consumers
|
|
:idprefix:
|
|
:idseparator: -
|
|
|
|
In this section we will discuss how Apache ActiveMQ Artemis can be configured to deal with slow consumers.
|
|
A slow consumer with a server-side queue (e.g. JMS topic subscriber) can pose a significant problem for broker performance.
|
|
If messages build up in the consumer's server-side queue then memory will begin filling up and the broker may enter paging mode which would impact performance negatively.
|
|
However, criteria can be set so that consumers which don't acknowledge messages quickly enough can potentially be disconnected from the broker, which in the case of a non-durable JMS subscriber, would allow the broker to remove the subscription and all of its messages freeing up valuable server resources.
|
|
|
|
== Required Configuration
|
|
|
|
By default the server will not detect slow consumers.
|
|
If slow consumer detection is desired then see xref:address-model.adoc#address-model[address model chapter] for more details on the required address settings.
|
|
|
|
The calculation to determine whether or not a consumer is slow only inspects the number of messages a particular consumer has _acknowledged_.
|
|
It doesn't take into account whether or not flow control has been enabled on the consumer, whether or not the consumer is streaming a large message, etc.
|
|
Keep this in mind when configuring slow consumer detection.
|
|
|
|
Please note that slow consumer checks are performed using the scheduled thread pool and that each queue on the broker with slow consumer detection enabled will cause a new entry in the internal `java.util.concurrent.ScheduledThreadPoolExecutor` instance.
|
|
If there are a high number of queues and the `slow-consumer-check-period` is relatively low then there may be delays in executing some of the checks.
|
|
However, this will not impact the accuracy of the calculations used by the detection algorithm.
|
|
See xref:thread-pooling.adoc#thread-management[thread pooling] for more details about this pool.
|
|
|
|
== Example
|
|
|
|
See the xref:examples.adoc#slow-consumer[slow consumer example] which shows how to detect a slow consumer with Apache ActiveMQ Artemis.
|