From 5102af5fc3e86a432e9e91f82efec90d305f3e6c Mon Sep 17 00:00:00 2001 From: rutuja Date: Wed, 3 Jun 2026 23:02:14 -0700 Subject: [PATCH] Edits done by Rutuja to the layout --- modules/ROOT/pages/index.adoc | 2 +- ...ring-broker-metrics-queues-and-topics.adoc | 58 +++++----- ...ing-and-configuring-an-ha-broker-pair.adoc | 2 +- .../pages/amq-broker-architecture.adoc | 1 - .../pages/amq-broker-overview.adoc | 1 - .../introduction-to-red-hat-amq-broker.adoc | 1 - .../pages/amqp-protocol-client-examples.adoc | 1 - ...and-consumers-with-java-core-protocol.adoc | 2 + ...implementing-point-to-point-messaging.adoc | 105 ++++++------------ ...roker-operator-via-cli-or-operatorhub.adoc | 12 +- ...-platform-fundamentals-for-amq-broker.adoc | 1 - ...ge-stores-for-amq-broker-on-openshift.adoc | 1 - ...lient-connections-for-external-access.adoc | 20 ++-- ...nd-best-practices-for-external-access.adoc | 6 +- ...d-use-cases-of-asynchronous-messaging.adoc | 78 ++++++------- ...terns-point-to-point-publishsubscribe.adoc | 4 +- ...pts-producers-consumers-queues-topics.adoc | 3 +- ...erview-of-message-oriented-middleware.adoc | 1 - ...llocations-cpu-memory-for-broker-pods.adoc | 1 - ...erformance-considerations-for-scaling.adoc | 1 - .../scaling-amq-broker-on-openshift.adoc | 1 - .../pages/encrypting-connections.adoc | 1 - ...ating-external-identity-providers-idp.adoc | 1 - ...ficates-and-trust-stores-on-openshift.adoc | 2 - 24 files changed, 136 insertions(+), 170 deletions(-) diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 5f2f880..bb86608 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -46,5 +46,5 @@ Duration: 4 hours This course assumes that you have the following prior experience: * Understanding of Message Oriented Middleware and JMS -* Understanding on Containers, Kubernetes, and OpenShift +* Understanding of Containers, Kubernetes, and OpenShift * Understanding of basic Java \ No newline at end of file diff --git a/modules/accessing-management-console-for-amq-broker-on-openshift/pages/monitoring-broker-metrics-queues-and-topics.adoc b/modules/accessing-management-console-for-amq-broker-on-openshift/pages/monitoring-broker-metrics-queues-and-topics.adoc index f8f9084..26a759f 100644 --- a/modules/accessing-management-console-for-amq-broker-on-openshift/pages/monitoring-broker-metrics-queues-and-topics.adoc +++ b/modules/accessing-management-console-for-amq-broker-on-openshift/pages/monitoring-broker-metrics-queues-and-topics.adoc @@ -13,33 +13,37 @@ The OpenShift monitoring stack can also integrate with this, as indicated by the Monitoring an AMQ Broker involves keeping an eye on several key aspects: -* *Broker Health Metrics*: These provide an overall picture of the broker's operational state. Key metrics include: - * CPU usage and memory consumption of broker pods. - * JVM statistics (heap usage, garbage collection activity). - * File descriptor usage. - * Total connection counts and session counts. - * Message processing rates (messages added, delivered, acknowledged). -* *Queue Metrics*: These offer insights into message flow and potential bottlenecks within specific queues. Important queue metrics include: - * `MessageCount`: The number of messages currently awaiting consumption in the queue. - * `Consumers`: The count of active message consumers connected to the queue. - * `Producers`: The count of active message producers sending to the queue. - * `MessagesAdded`: The total number of messages ever added to the queue since the broker started. - * `MessagesAcknowledged`: The total number of messages successfully processed and acknowledged by consumers. - * `DeliveringCount`: Messages currently in the process of being delivered to consumers. - * `ScheduledCount`: Messages scheduled for future delivery. - * `ExpiredCount`: Messages that have passed their Time-To-Live (TTL) and have expired. -* *Topic Metrics*: While ActiveMQ Artemis internally manages topics via durable subscriptions on specific queues, monitoring involves observing the queues associated with these subscriptions. Key topic-related metrics (observed on durable subscription queues) include: - * `MessageCount`: Messages pending for a specific durable subscriber. - * `ConsumerCount`: Number of active consumers for a durable subscription. - * Message publication rates and consumption rates. -* *Connection Metrics*: Details about client connections can help diagnose connectivity issues. This includes: - * Number of active client connections per protocol. - * Connection duration. - * Remote address of connected clients. -* *Message Store Metrics*: These indicate the health and performance of message persistence. - * Disk usage for the message journal and paging files. - * Journal write rates. - * Paging file sizes and counts. +* **Broker Health Metrics:** These provide an overall picture of the broker's operational state. Key metrics include: +** CPU usage and memory consumption of broker pods. +** JVM statistics (heap usage, garbage collection activity). +** File descriptor usage. +** Total connection counts and session counts. +** Message processing rates (messages added, delivered, acknowledged). + +* **Queue Metrics:** These offer insights into message flow and potential bottlenecks within specific queues. Important queue metrics include: +** `MessageCount`: The number of messages currently awaiting consumption in the queue. +** `Consumers`: The count of active message consumers connected to the queue. +** `Producers`: The count of active message producers sending to the queue. +** `MessagesAdded`: The total number of messages ever added to the queue since the broker started. +** `MessagesAcknowledged`: The total number of messages successfully processed and acknowledged by consumers. +** `DeliveringCount`: Messages currently in the process of being delivered to consumers. +** `ScheduledCount`: Messages scheduled for future delivery. +** `ExpiredCount`: Messages that have passed their Time-To-Live (TTL) and have expired. + +* **Topic Metrics:** While ActiveMQ Artemis internally manages topics via durable subscriptions on specific queues, monitoring involves observing the queues associated with these subscriptions. Key topic-related metrics (observed on durable subscription queues) include: +** `MessageCount`: Messages pending for a specific durable subscriber. +** `ConsumerCount`: Number of active consumers for a durable subscription. +** Message publication rates and consumption rates. + +* **Connection Metrics:** Details about client connections can help diagnose connectivity issues. This includes: +** Number of active client connections per protocol. +** Connection duration. +** Remote address of connected clients. + +* **Message Store Metrics:** These indicate the health and performance of message persistence. +** Disk usage for the message journal and paging files. +** Journal write rates. +** Paging file sizes and counts. [[hawtio-console-for-monitoring]] == Monitoring with the Hawtio Management Console diff --git a/modules/amq-broker-high-availability-on-openshift/pages/deploying-and-configuring-an-ha-broker-pair.adoc b/modules/amq-broker-high-availability-on-openshift/pages/deploying-and-configuring-an-ha-broker-pair.adoc index c7308e9..b4e75d9 100644 --- a/modules/amq-broker-high-availability-on-openshift/pages/deploying-and-configuring-an-ha-broker-pair.adoc +++ b/modules/amq-broker-high-availability-on-openshift/pages/deploying-and-configuring-an-ha-broker-pair.adoc @@ -292,7 +292,7 @@ You will observe: * `ha-broker-pair1-ss-0` transitioning to `Terminating`. * `ha-broker-pair2-ss-0 ` remaining `Running` and, in its logs, becoming the new `LIVE` broker. * A new `ha-broker-pair1-ss-0` pod being created, transitioning through `Pending`, then `Running`, and eventually becoming the new `BACKUP` broker. -+ + This demonstrates the automatic failover and self-healing capabilities of an Operator-managed HA broker pair, ensuring continuous availability of your messaging infrastructure. This lab provides a robust, operator-managed Shared Database (JDBC) Live-Backup HA setup, which is a common and highly recommended configuration for AMQ Broker on OpenShift, offering strong guarantees against message loss and downtime. \ No newline at end of file diff --git a/modules/amq-broker-overview/pages/amq-broker-architecture.adoc b/modules/amq-broker-overview/pages/amq-broker-architecture.adoc index 1c18a9b..d5719aa 100644 --- a/modules/amq-broker-overview/pages/amq-broker-architecture.adoc +++ b/modules/amq-broker-overview/pages/amq-broker-architecture.adoc @@ -1,6 +1,5 @@ # AMQ Broker Architecture -= AMQ Broker Architecture The Red Hat AMQ Broker, built upon the robust Apache ActiveMQ Artemis project, is a high-performance, asynchronous messaging system. Understanding its architecture is crucial for effective deployment, management, and troubleshooting, especially when operating within a container orchestration platform like OpenShift. diff --git a/modules/amq-broker-overview/pages/amq-broker-overview.adoc b/modules/amq-broker-overview/pages/amq-broker-overview.adoc index dc5d99c..5521bf9 100644 --- a/modules/amq-broker-overview/pages/amq-broker-overview.adoc +++ b/modules/amq-broker-overview/pages/amq-broker-overview.adoc @@ -1,6 +1,5 @@ # AMQ Broker Overview -=== AMQ Broker Overview Red Hat AMQ Broker is a flexible, high-performance, and lightweight message broker built on xref:amq-broker-on-openshift-deployment-and-management.adoc#_foundations_in_apache_activemq_artemis[Apache ActiveMQ Artemis]. It facilitates asynchronous messaging by acting as xref:amq-broker-on-openshift-deployment-and-management.adoc#_introduction_to_message_oriented_middleware_mom[Message-Oriented Middleware (MOM)]. diff --git a/modules/amq-broker-overview/pages/introduction-to-red-hat-amq-broker.adoc b/modules/amq-broker-overview/pages/introduction-to-red-hat-amq-broker.adoc index cb27294..96a823d 100644 --- a/modules/amq-broker-overview/pages/introduction-to-red-hat-amq-broker.adoc +++ b/modules/amq-broker-overview/pages/introduction-to-red-hat-amq-broker.adoc @@ -1,7 +1,6 @@ # Introduction to Red Hat AMQ Broker [#_introduction_to_red_hat_amq_broker] -= Introduction to Red Hat AMQ Broker This section provides a foundational understanding of Red Hat AMQ Broker, covering its identity, underlying technology, core features, supported messaging protocols, and architectural overview. Mastering these introductory concepts is essential before proceeding to its deployment and management on OpenShift. diff --git a/modules/amqp-protocol-client-examples/pages/amqp-protocol-client-examples.adoc b/modules/amqp-protocol-client-examples/pages/amqp-protocol-client-examples.adoc index 0f0791e..772d54f 100644 --- a/modules/amqp-protocol-client-examples/pages/amqp-protocol-client-examples.adoc +++ b/modules/amqp-protocol-client-examples/pages/amqp-protocol-client-examples.adoc @@ -1,6 +1,5 @@ # AMQP Protocol Client Examples -=== AMQP Protocol Client Examples * Introduces the AMQP 1.0 standard, a widely adopted messaging protocol. * Covers setting up development environments for AMQP clients, such as using Red Hat build of Apache Qpid JMS for Java. diff --git a/modules/core-protocol-client-examples/pages/developing-producers-and-consumers-with-java-core-protocol.adoc b/modules/core-protocol-client-examples/pages/developing-producers-and-consumers-with-java-core-protocol.adoc index 8959647..0992fa5 100644 --- a/modules/core-protocol-client-examples/pages/developing-producers-and-consumers-with-java-core-protocol.adoc +++ b/modules/core-protocol-client-examples/pages/developing-producers-and-consumers-with-java-core-protocol.adoc @@ -21,6 +21,8 @@ To effectively develop a Java Core Protocol client, it's crucial to understand t .The relationship between ConnectionFactory, Connection, Session, Producer, and Consumer image::core-protocol-components.png[Core Protocol Client Components, 600, 400] +// no image aaded here, please add + [NOTE] As highlighted in the provided context, the Core Protocol JMS client library allows for advanced features like flow control. You can configure `ConnectionFactory` properties such as `setConsumerWindowSize()` and `setProducerWindowSize()` to regulate the flow of messages and prevent resource exhaustion, especially in scenarios with varying producer and consumer speeds. For basic examples, default settings are often sufficient, but for performance-critical or high-volume applications, understanding and tuning these settings is crucial. diff --git a/modules/core-protocol-client-examples/pages/implementing-point-to-point-messaging.adoc b/modules/core-protocol-client-examples/pages/implementing-point-to-point-messaging.adoc index 13d6828..cf4eda7 100644 --- a/modules/core-protocol-client-examples/pages/implementing-point-to-point-messaging.adoc +++ b/modules/core-protocol-client-examples/pages/implementing-point-to-point-messaging.adoc @@ -30,7 +30,7 @@ To implement P2P messaging with AMQ Broker using a Java client, you will: In this hands-on lab, you will deploy a simple AMQ Broker instance on OpenShift (if not already done in a previous lab) and then develop Java JMS clients to demonstrate point-to-point messaging. -===== Prerequisites +==== Prerequisites Before you begin, ensure the following: @@ -40,7 +40,7 @@ Before you begin, ensure the following: * You have a Java Development Kit (JDK) 11 or later installed. * Apache Maven is installed for project management. -===== Step 1: Set Up the Client Development Environment +==== Step 1: Set Up the Client Development Environment Create a new Maven project for your JMS clients. @@ -129,7 +129,7 @@ cd amq-p2p-client <6> Jakarta EE API provides the core `jakarta.jms` interfaces. `provided` scope means it's expected to be available at runtime, but for a standalone client, you might include it directly. <7> Qpid JMS client for AMQP 1.0, though not strictly needed for the Core Protocol example, it's a common messaging client. We'll focus on the `artemis-jakarta-client` for core protocol JMS. -===== Step 2: Implement the JMS Message Producer (Sender) +==== Step 2: Implement the JMS Message Producer (Sender) We will adapt the `Sender` example from the provided context. This client will connect to the AMQ Broker and send a text message to a queue. @@ -218,7 +218,7 @@ public class JMSSender { * Replace `` and `` with the actual values for your AMQ Broker's external route or service. You can usually find this by inspecting the OpenShift Route or Service for your broker. For instance, if your broker is named `mybroker`, you might look for a route like `mybroker-amqp-0-svc-headless` or `mybroker-amqp-0-svc-external`. The default OpenWire port for AMQ Broker is `61616`. * The `JMSInitialContextFactory` is used to programmatically configure JNDI lookups without an external `jndi.properties` file. It maps `myFactoryLookup` to your broker URL and `myQueue` to an actual queue named `myQueue` on the broker. -===== Step 3: Implement the JMS Message Consumer (Receiver) +==== Step 3: Implement the JMS Message Consumer (Receiver) Now, create a consumer client that will connect to the same queue and receive messages sent by the producer. @@ -295,7 +295,7 @@ public class JMSReceiver { * Again, ensure `` and `` are correctly configured. * The `messageConsumer.receive()` call is blocking; it will wait until a message is available. For continuous consumption, you would typically use `receive(timeout)` or an asynchronous `MessageListener`. -===== Step 4: Deploy a Basic AMQ Broker Instance (if not already done) +==== Step 4: Deploy a Basic AMQ Broker Instance (if not already done) If you don't have an AMQ Broker instance running, deploy one now. @@ -394,7 +394,7 @@ oc get route mybroker-core-route -n amq-broker-p2p -o jsonpath='{.spec.host}' ---- Update the `brokerUrl` in `JMSSender.java` and `JMSReceiver.java` with the retrieved host and port. For a service, it might be `mybroker-core-svc.amq-broker-p2p.svc.cluster.local:61616` if clients are within the same OpenShift cluster, or an external IP/hostname if exposed differently. -===== Step 5: Run the P2P Clients +==== Step 5: Run the P2P Clients . Compile the Java clients: + @@ -433,7 +433,7 @@ The receiver successfully processed the message and then exited because `receive This demonstrates the fundamental point-to-point behavior: the message was sent to `myQueue` and consumed by a single receiver. -===== Step 6: Verify with Hawtio Management Console +==== Step 6: Verify with Hawtio Management Console You can also monitor the queue and message activity using the Hawtio management console. @@ -463,37 +463,6 @@ Access this URL in your web browser. * *Error Handling*: Implement robust `try-catch-finally` blocks and `ExceptionListener` to handle connection failures and other JMS exceptions gracefully. * *Security*: For production environments, always enable authentication and authorization on the AMQ Broker. Use SSL/TLS for client-broker communication as covered in the "Securing AMQ Broker on OpenShift" section. -By following these steps, you have successfully implemented and tested point-to-point messaging using Java JMS clients with an AMQ Broker deployed on OpenShift. You've seen how messages are sent to a queue and consumed by a single recipient, demonstrating a fundamental messaging pattern. -++++ -The output successfully addresses the topic "Implementing Point-to-Point Messaging" using the specified format and guidelines. - -1. **Detailed Technical Explanation**: - * Introduced P2P messaging, its characteristics (queues, one-to-one, persistence, load balancing, ordered delivery), and use cases. - * Explained how AMQ Broker supports P2P via JMS with Java core protocol clients. - * Described the role of queues, producers, and consumers. - -2. **Hands-on Activities**: - * **Prerequisites**: Clearly listed necessary components (OpenShift, Operator, Broker instance, JDK, Maven). - * **Client Development Environment Setup**: Step-by-step instructions for creating a Maven project and configuring `pom.xml` with relevant dependencies (Jakarta JMS, ActiveMQ Artemis client). - * **JMS Message Producer (Sender)**: - * Provided a complete, runnable `JMSSender.java` code. - * Annotated the code with explanations mirroring the context's numbered points for `Sender` (InitialContext, ConnectionFactory, Connection, Session, MessageProducer, TextMessage, Send, Close). - * Included placeholders for broker host/port, emphasizing customization. - * **JMS Message Consumer (Receiver)**: - * Provided a complete, runnable `JMSReceiver.java` code. - * Annotated the code with explanations for the receiving process. - * **Broker Deployment**: Included a basic `Broker` Custom Resource (CR) for deploying an AMQ Broker instance on OpenShift, including `core` acceptor and `myQueue` definition, with simplified authentication for the lab. - * **Running Clients**: Clear `mvn exec:java` commands for both sender and receiver, with instructions on observing output. - * **Verification**: Steps to verify messages using the Hawtio management console. - -3. **Adherence to Constraints**: - * **Antora AsciiDoc format**: Used `====` for sections, `[source,java]` and `[source,bash]` for code blocks, numbered lists for steps, and italic/bold formatting. - * **Content Architect role**: Simplified complex concepts (P2P model), provided clear code examples, and offered expert-level insights and troubleshooting. - * **Use of provided context**: Explicitly referenced and adapted the `Sender` example's structure and explanation points from the context. The context also guided the choice of Java JMS as the "Core Protocol Client Example." - * **Technical accuracy, engagement, inclusiveness, adaptability**: The content is technically sound, uses clear language, and the structure makes it adaptable for different learning paces. - * **Sticking to the topic**: Focused solely on Point-to-Point messaging implementation. - -The response is comprehensive and directly addresses the prompt.++++ = Implementing Point-to-Point Messaging This section delves into the fundamentals of Point-to-Point (P2P) messaging, a core concept in message-oriented middleware (MOM). We will explore how to implement P2P messaging using Java clients with Red Hat AMQ Broker, focusing on the Java Message Service (JMS) API, which underpins the AMQ Broker's core protocol client capabilities. @@ -504,11 +473,11 @@ Point-to-Point (P2P) messaging is a messaging model where messages are sent from Key characteristics of P2P messaging: -* *Queues*: Messages are typically sent to and consumed from a message queue. A queue acts as a holding area for messages until a consumer is ready to retrieve them. -* *One-to-One Delivery*: Even if multiple consumers are listening to the same queue, each message is delivered to only one of them. Once a message is consumed, it is removed from the queue. -* *Persistence*: Messages in a queue can be made persistent, meaning they survive broker restarts. This ensures messages are not lost even if the broker goes offline before they are consumed. -* *Load Balancing*: If multiple consumers are connected to the same queue, the broker can distribute messages among them, effectively balancing the load. -* *Ordered Delivery*: Messages are generally delivered to consumers in the order they were sent to the queue. +* **Queues:** Messages are typically sent to and consumed from a message queue. A queue acts as a holding area for messages until a consumer is ready to retrieve them. +* **One-to-One Delivery:** Even if multiple consumers are listening to the same queue, each message is delivered to only one of them. Once a message is consumed, it is removed from the queue. +* **Persistence:** Messages in a queue can be made persistent, meaning they survive broker restarts. This ensures messages are not lost even if the broker goes offline before they are consumed. +* **Load Balancing:** If multiple consumers are connected to the same queue, the broker can distribute messages among them, effectively balancing the load. +* **Ordered Delivery:** Messages are generally delivered to consumers in the order they were sent to the queue. Common use cases for P2P messaging include task distribution, command processing, and integrating applications where a specific action needs to be performed once. @@ -518,9 +487,9 @@ Red Hat AMQ Broker, based on Apache ActiveMQ Artemis, provides robust support fo To implement P2P messaging with AMQ Broker using a Java client, you will: -1. **Define a Queue**: On the AMQ Broker, a queue is a named destination where messages are sent and from which they are retrieved. -2. **Create a Producer**: A producer application creates and sends messages to a specific queue. -3. **Create a Consumer**: A consumer application connects to the same queue and retrieves messages. +1. **Define a Queue:** On the AMQ Broker, a queue is a named destination where messages are sent and from which they are retrieved. +2. **Create a Producer:** A producer application creates and sends messages to a specific queue. +3. **Create a Consumer:** A consumer application connects to the same queue and retrieves messages. ==== Hands-on Activity: Implementing a P2P Java JMS Client @@ -530,11 +499,11 @@ In this hands-on lab, you will deploy a simple AMQ Broker instance on OpenShift Before you begin, ensure the following: -* You have access to an OpenShift cluster. -* The AMQ Broker Operator is installed on your OpenShift cluster. -* An AMQ Broker instance is deployed and running, with external access configured (e.g., via a standard `broker` custom resource). For this lab, we'll assume a basic broker named `mybroker` is deployed in a namespace, and its console or client-facing routes are accessible. -* You have a Java Development Kit (JDK) 11 or later installed. -* Apache Maven is installed for project management. +* You have access to an OpenShift cluster. +* The AMQ Broker Operator is installed on your OpenShift cluster. +* An AMQ Broker instance is deployed and running, with external access configured (e.g., via a standard `broker` custom resource). For this lab, we'll assume a basic broker named `mybroker` is deployed in a namespace, and its console or client-facing routes are accessible. +* You have a Java Development Kit (JDK) 11 or later installed. +* Apache Maven is installed for project management. ===== Step 1: Set Up the Client Development Environment @@ -711,8 +680,8 @@ public class JMSSender { } } ---- -* Replace `` and `` with the actual values for your AMQ Broker's external route or service. You can usually find this by inspecting the OpenShift Route or Service for your broker. For instance, if your broker is named `mybroker`, you might look for a route like `mybroker-amqp-0-svc-headless` or `mybroker-amqp-0-svc-external`. The default OpenWire port for AMQ Broker is `61616`. -* The `JMSInitialContextFactory` is used to programmatically configure JNDI lookups without an external `jndi.properties` file. It maps `myFactoryLookup` to your broker URL and `myQueue` to an actual queue named `myQueue` on the broker. +* Replace `` and `` with the actual values for your AMQ Broker's external route or service. You can usually find this by inspecting the OpenShift Route or Service for your broker. For instance, if your broker is named `mybroker`, you might look for a route like `mybroker-amqp-0-svc-headless` or `mybroker-amqp-0-svc-external`. The default OpenWire port for AMQ Broker is `61616`. +* The `JMSInitialContextFactory` is used to programmatically configure JNDI lookups without an external `jndi.properties` file. It maps `myFactoryLookup` to your broker URL and `myQueue` to an actual queue named `myQueue` on the broker. ===== Step 3: Implement the JMS Message Consumer (Receiver) @@ -788,8 +757,8 @@ public class JMSReceiver { } } ---- -* Again, ensure `` and `` are correctly configured. -* The `messageConsumer.receive()` call is blocking; it will wait until a message is available. For continuous consumption, you would typically use `receive(timeout)` or an asynchronous `MessageListener`. +* Again, ensure `` and `` are correctly configured. +* The `messageConsumer.receive()` call is blocking; it will wait until a message is available. For continuous consumption, you would typically use `receive(timeout)` or an asynchronous `MessageListener`. ===== Step 4: Deploy a Basic AMQ Broker Instance (if not already done) @@ -947,16 +916,16 @@ Access this URL in your web browser. ==== Troubleshooting and Best Practices -* *Connection Issues*: Double-check the `brokerUrl` in your client code. Ensure the OpenShift route or service is correctly exposed and accessible from where you are running the client. Firewalls or network policies might block connections. -* *JNDI Lookup Failures*: Ensure `jmsFactoryName` and `queueName` in your client code match what's configured in the `Properties` for `InitialContext`. -* *No Message Received*: - * Verify the sender ran successfully and reported "Sent message." - * Check the Hawtio console for the `myQueue` to see if the message is enqueued. If it is, the problem is with the consumer. If not, the problem is with the producer or broker configuration. - * Ensure the queue name is identical in both sender and receiver. -* *Efficiency*: As noted in the context, creating and closing a `Connection`, `Session`, and `MessageProducer`/`MessageConsumer` for every single message is inefficient. In real-world applications, you should use long-lived connections and sessions, and create producers/consumers once, reusing them for multiple messages. -* *Persistence*: For critical messages that must not be lost, ensure `DeliveryMode.PERSISTENT` is used by the producer, and your AMQ Broker is configured with a persistent message store (e.g., a JDBC store or file-based store with `PersistentVolumeClaim`). -* *Acknowledgements*: `Session.AUTO_ACKNOWLEDGE` is convenient but might not be suitable for all scenarios. Other acknowledgement modes like `CLIENT_ACKNOWLEDGE` or `DUPS_OK_ACKNOWLEDGE` provide more control over when messages are considered consumed. For robust applications, using `CLIENT_ACKNOWLEDGE` or transactional sessions is often preferred. -* *Error Handling*: Implement robust `try-catch-finally` blocks and `ExceptionListener` to handle connection failures and other JMS exceptions gracefully. -* *Security*: For production environments, always enable authentication and authorization on the AMQ Broker. Use SSL/TLS for client-broker communication as covered in the "Securing AMQ Broker on OpenShift" section. - -By following these steps, you have successfully implemented and tested point-to-point messaging using Java JMS clients with an AMQ Broker deployed on OpenShift. You've seen how messages are sent to a queue and consumed by a single recipient, demonstrating a fundamental messaging pattern. +* **Connection Issues:** Double-check the `brokerUrl` in your client code. Ensure the OpenShift route or service is correctly exposed and accessible from where you are running the client. Firewalls or network policies might block connections. +* **JNDI Lookup Failures:** Ensure `jmsFactoryName` and `queueName` in your client code match what's configured in the `Properties` for `InitialContext`. +* **No Message Received:** +** Verify the sender ran successfully and reported "Sent message." +** Check the Hawtio console for the `myQueue` to see if the message is enqueued. If it is, the problem is with the consumer. If not, the problem is with the producer or broker configuration. +** Ensure the queue name is identical in both sender and receiver. +* **Efficiency:** As noted in the context, creating and closing a `Connection`, `Session`, and `MessageProducer`/`MessageConsumer` for every single message is inefficient. In real-world applications, you should use long-lived connections and sessions, and create producers/consumers once, reusing them for multiple messages. +* **Persistence:** For critical messages that must not be lost, ensure `DeliveryMode.PERSISTENT` is used by the producer, and your AMQ Broker is configured with a persistent message store (e.g., a JDBC store or file-based store with `PersistentVolumeClaim`). +* **Acknowledgements:** `Session.AUTO_ACKNOWLEDGE` is convenient but might not be suitable for all scenarios. Other acknowledgement modes like `CLIENT_ACKNOWLEDGE` or `DUPS_OK_ACKNOWLEDGE` provide more control over when messages are considered consumed. For robust applications, using `CLIENT_ACKNOWLEDGE` or transactional sessions is often preferred. +* **Error Handling:** Implement robust `try-catch-finally` blocks and `ExceptionListener` to handle connection failures and other JMS exceptions gracefully. +* **Security:** For production environments, always enable authentication and authorization on the AMQ Broker. Use SSL/TLS for client-broker communication as covered in the "Securing AMQ Broker on OpenShift" section. + +By following these steps, you have successfully implemented and tested point-to-point messaging using Java JMS clients with an AMQ Broker deployed on OpenShift. You've seen how messages are sent to a queue and consumed by a single recipient, demonstrating a fundamental messaging pattern. \ No newline at end of file diff --git a/modules/deploying-amq-broker-on-openshift/pages/installing-the-amq-broker-operator-via-cli-or-operatorhub.adoc b/modules/deploying-amq-broker-on-openshift/pages/installing-the-amq-broker-operator-via-cli-or-operatorhub.adoc index e70620c..a1dc936 100644 --- a/modules/deploying-amq-broker-on-openshift/pages/installing-the-amq-broker-operator-via-cli-or-operatorhub.adoc +++ b/modules/deploying-amq-broker-on-openshift/pages/installing-the-amq-broker-operator-via-cli-or-operatorhub.adoc @@ -21,7 +21,7 @@ Regardless of the method chosen, once the Operator is deployed, it continuously The CLI method offers precise control over the installation process, making it suitable for environments requiring specific version deployments or integration into CI/CD pipelines. -=== Prerequisites +== Prerequisites Before proceeding with the CLI installation, ensure you have the following: @@ -30,7 +30,7 @@ Before proceeding with the CLI installation, ensure you have the following: * The AMQ Broker Operator installation archive (`amq-broker-operator-7.13.3-ocp-install-examples-rhel9.zip` or similar) downloaded from the Red Hat Customer Portal. This archive contains the necessary deployment files, including `operator.yaml`. * An existing OpenShift project where you intend to manage your AMQ Broker deployments. -=== Hands-on Activity: Deploying the Operator via CLI +== Hands-on Activity: Deploying the Operator via CLI Follow these steps to install the AMQ Broker Operator using the OpenShift CLI. @@ -41,6 +41,7 @@ You need to download the AMQ Broker Operator installation files from the Red Hat . Locate the `AMQ Broker 7.13.3 Operator Installation and Example Files` and click `Download`. The `amq-broker-operator-7.13.3-ocp-install-examples-rhel9.zip` archive will download automatically. .Extract the Operator Files + Once downloaded, prepare a directory and extract the contents of the archive. . Create a new directory for your operator files: @@ -74,6 +75,7 @@ $ unzip amq-broker-operator-7.13.3-ocp-install-examples-rhel9.zip This will create a `amq-broker-operator-7.13.3-ocp-install-examples` directory containing the `deploy` folder and other example files. .Log in to OpenShift and Select Project + You need to log in to your OpenShift cluster as an administrator and switch to the project where you want to install the Operator. . Log in to your OpenShift cluster: @@ -95,6 +97,7 @@ $ oc project Replace `` with the name of your target OpenShift project (e.g., `amq-broker-project`). .Deploy the Operator + The necessary deployment manifests are found within the extracted `deploy` directory. . Navigate to the `deploy` directory within the extracted operator files: @@ -114,6 +117,7 @@ $ oc apply -f operator.yaml This command creates the necessary Kubernetes resources (Deployment, Service Account, ClusterRole, ClusterRoleBinding, etc.) that constitute the AMQ Broker Operator. .Verify Operator Deployment + Confirm that the Operator pod is running successfully. . Check the status of the Operator's deployment: @@ -154,7 +158,7 @@ Once the Operator pod is running, the AMQ Broker Operator is successfully instal For a more guided and graphical installation experience, OperatorHub in the OpenShift web console is the recommended method. -=== Prerequisites +== Prerequisites Before installing via OperatorHub, ensure you meet the following conditions: @@ -167,7 +171,7 @@ Before installing via OperatorHub, ensure you meet the following conditions: In OperatorHub, you can typically only install the latest Operator version provided in each channel. If you require an earlier version of an Operator, you *must* install it by using the CLI, as described in xref:deploying-amq-broker-on-openshift.adoc#installing-the-operator-using-the-cli[Installing the Operator using the CLI]. ==== -=== Hands-on Activity: Deploying the Operator via OperatorHub +== Hands-on Activity: Deploying the Operator via OperatorHub Follow these steps to install the AMQ Broker Operator using the OpenShift web console's OperatorHub. diff --git a/modules/deploying-amq-broker-on-openshift/pages/openshift-container-platform-fundamentals-for-amq-broker.adoc b/modules/deploying-amq-broker-on-openshift/pages/openshift-container-platform-fundamentals-for-amq-broker.adoc index 2d888b9..285df40 100644 --- a/modules/deploying-amq-broker-on-openshift/pages/openshift-container-platform-fundamentals-for-amq-broker.adoc +++ b/modules/deploying-amq-broker-on-openshift/pages/openshift-container-platform-fundamentals-for-amq-broker.adoc @@ -5,7 +5,6 @@ ifndef::internal[] :description: Understand the foundational concepts of OpenShift Container Platform essential for deploying and managing Red Hat AMQ Broker. endif::internal[] -= OpenShift Container Platform Fundamentals for AMQ Broker This section provides an essential overview of OpenShift Container Platform (OCP) concepts critical for deploying, managing, and scaling Red Hat AMQ Broker. Understanding these fundamentals will empower you to effectively leverage the power of OCP for your messaging infrastructure. diff --git a/modules/different-message-stores-for-amq-broker-on-openshift/pages/different-message-stores-for-amq-broker-on-openshift.adoc b/modules/different-message-stores-for-amq-broker-on-openshift/pages/different-message-stores-for-amq-broker-on-openshift.adoc index 1aeab9a..e706417 100644 --- a/modules/different-message-stores-for-amq-broker-on-openshift/pages/different-message-stores-for-amq-broker-on-openshift.adoc +++ b/modules/different-message-stores-for-amq-broker-on-openshift/pages/different-message-stores-for-amq-broker-on-openshift.adoc @@ -1,6 +1,5 @@ # Different Message Stores for AMQ Broker on OpenShift -=== Different Message Stores for AMQ Broker on OpenShift AMQ Broker uses message stores for persistence, ensuring message durability and reliability. On OpenShift, various strategies are available: diff --git a/modules/enabling-external-access-to-brokers-deployed-on-openshift/pages/configuring-client-connections-for-external-access.adoc b/modules/enabling-external-access-to-brokers-deployed-on-openshift/pages/configuring-client-connections-for-external-access.adoc index 5bd62ad..9f5b9e8 100644 --- a/modules/enabling-external-access-to-brokers-deployed-on-openshift/pages/configuring-client-connections-for-external-access.adoc +++ b/modules/enabling-external-access-to-brokers-deployed-on-openshift/pages/configuring-client-connections-for-external-access.adoc @@ -199,19 +199,19 @@ This lab demonstrates how to connect a simple Java-based Core protocol client to Identify the hostname of the external route pointing to your broker's `my-acceptor`. .Execute the following command on your OpenShift CLI: -+ + [source,bash] ---- OCP_PROJECT=$(oc project -q) BROKER_ROUTE=$(oc get route my-broker-my-acceptor -o jsonpath='{.spec.host}') echo "AMQ Broker Route: ${BROKER_ROUTE}" ---- -+ + [output] ---- AMQ Broker Route: my-broker-my-acceptor-my-openshift-project.apps.your-openshift-domain.com ---- -+ + Make a note of this hostname; you will use it in your client application. ==== 2. Create a Maven Project for the Client @@ -219,14 +219,14 @@ Make a note of this hostname; you will use it in your client application. Create a new Maven project for your Java Core client. .On your local machine, create a new directory for your project: -+ + [source,bash] ---- mkdir amq-external-client && cd amq-external-client ---- .Create a `pom.xml` file with the necessary dependencies for the AMQ Broker Core client: -+ + [source,xml] ---- ` and `` with your actual passwords. -===== AMQP Client with One-Way TLS +==== AMQP Client with One-Way TLS For an external AMQP client using one-way TLS, the connection URL uses `amqps://` and includes parameters for the trust store. The `transport.verifyHost=true` parameter is crucial for host name verification, preventing man-in-the-middle attacks. @@ -82,7 +82,7 @@ transport.verifyHost=true&transport.trustStoreLocation=~/client.ts&transport.tru * Replace `my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain` with the actual route hostname. * Replace `` with your actual password. -===== AMQP Client with Two-Way TLS +==== AMQP Client with Two-Way TLS For an external AMQP client using two-way TLS, both the key store and trust store parameters are included in the connection URL. diff --git a/modules/overview-of-message-oriented-middleware/pages/benefits-and-use-cases-of-asynchronous-messaging.adoc b/modules/overview-of-message-oriented-middleware/pages/benefits-and-use-cases-of-asynchronous-messaging.adoc index 1f4e5fc..eaea540 100644 --- a/modules/overview-of-message-oriented-middleware/pages/benefits-and-use-cases-of-asynchronous-messaging.adoc +++ b/modules/overview-of-message-oriented-middleware/pages/benefits-and-use-cases-of-asynchronous-messaging.adoc @@ -12,60 +12,60 @@ This fundamental shift brings several significant benefits, making it an indispe === Key Benefits of Asynchronous Messaging -* **Decoupling (Loose Coupling):** - * **Technical Explanation:** Producers and consumers do not need to be aware of each other's direct network location, availability, or implementation details. They only need to agree on a common message format and a destination on the message broker. This architectural pattern isolates components, preventing failures in one service from directly impacting others. Services can evolve and be deployed independently, reducing inter-service dependencies. - * **Impact:** Reduces complex dependencies, simplifies overall system design, and allows for independent development, deployment, and scaling cycles for different microservices or applications. When using AMQ Broker on OpenShift, your application pods (producers/consumers) only need to know how to connect to the broker, not to each other directly. +* **Decoupling (Loose Coupling):** +** **Technical Explanation:** Producers and consumers do not need to be aware of each other's direct network location, availability, or implementation details. They only need to agree on a common message format and a destination on the message broker. This architectural pattern isolates components, preventing failures in one service from directly impacting others. Services can evolve and be deployed independently, reducing inter-service dependencies. +** **Impact:** Reduces complex dependencies, simplifies overall system design, and allows for independent development, deployment, and scaling cycles for different microservices or applications. When using AMQ Broker on OpenShift, your application pods (producers/consumers) only need to know how to connect to the broker, not to each other directly. -* **Resilience and Reliability:** - * **Technical Explanation:** Messages are persisted by the broker until successfully delivered and acknowledged by a consumer. If a consumer fails, is temporarily offline, or an error occurs during processing, messages are not lost and can be redelivered once the consumer recovers or after appropriate error handling. The broker acts as a buffer against system outages and spikes. Message acknowledgment mechanisms ensure that messages are only removed from the broker after successful processing. - * **Impact:** Enhances fault tolerance and guarantees message delivery. A transient failure of a processing service does not lead to data loss or user-facing errors. AMQ Broker's persistence options (such as file-based or JDBC message stores, which will be discussed in detail later) are crucial for ensuring message durability even if the broker itself restarts or undergoes failover in a high-availability setup. +* **Resilience and Reliability:** +** **Technical Explanation:** Messages are persisted by the broker until successfully delivered and acknowledged by a consumer. If a consumer fails, is temporarily offline, or an error occurs during processing, messages are not lost and can be redelivered once the consumer recovers or after appropriate error handling. The broker acts as a buffer against system outages and spikes. Message acknowledgment mechanisms ensure that messages are only removed from the broker after successful processing. +** **Impact:** Enhances fault tolerance and guarantees message delivery. A transient failure of a processing service does not lead to data loss or user-facing errors. AMQ Broker's persistence options (such as file-based or JDBC message stores, which will be discussed in detail later) are crucial for ensuring message durability even if the broker itself restarts or undergoes failover in a high-availability setup. -* **Scalability:** - * **Technical Explanation:** Components can scale independently. If the message production rate increases, more consumer instances can be added to process messages in parallel from the same destination (e.g., a queue), distributing the load effectively. Similarly, if a single producer experiences high load, it can quickly offload tasks to the broker without waiting for downstream services. This inherently supports horizontal scaling of consumer services by simply adding more pods on OpenShift. - * **Impact:** Systems can handle varying loads efficiently, dynamically adjusting to demand without requiring redesign. Red Hat AMQ Broker, especially when deployed in an HA configuration on OpenShift, can scale to handle high message throughput and a large number of concurrent connections. +* **Scalability:** +** **Technical Explanation:** Components can scale independently. If the message production rate increases, more consumer instances can be added to process messages in parallel from the same destination (e.g., a queue), distributing the load effectively. Similarly, if a single producer experiences high load, it can quickly offload tasks to the broker without waiting for downstream services. This inherently supports horizontal scaling of consumer services by simply adding more pods on OpenShift. +** **Impact:** Systems can handle varying loads efficiently, dynamically adjusting to demand without requiring redesign. Red Hat AMQ Broker, especially when deployed in an HA configuration on OpenShift, can scale to handle high message throughput and a large number of concurrent connections. -* **Improved Responsiveness:** - * **Technical Explanation:** For operations that involve long-running tasks or multiple sequential steps, a client can send a request as a message to the broker and receive an immediate acknowledgment that the message was accepted. The client doesn't have to wait for the entire, potentially lengthy, process to complete, freeing it to perform other tasks or respond to the user immediately. The actual processing happens in the background. - * **Impact:** Enhances user experience by reducing perceived latency for interactive applications. For example, a web application can immediately confirm an order placement to the user while the actual order fulfillment process (e.g., inventory check, payment processing, shipping notification) happens asynchronously via messaging. +* **Improved Responsiveness:** +** **Technical Explanation:** For operations that involve long-running tasks or multiple sequential steps, a client can send a request as a message to the broker and receive an immediate acknowledgment that the message was accepted. The client doesn't have to wait for the entire, potentially lengthy, process to complete, freeing it to perform other tasks or respond to the user immediately. The actual processing happens in the background. +** **Impact:** Enhances user experience by reducing perceived latency for interactive applications. For example, a web application can immediately confirm an order placement to the user while the actual order fulfillment process (e.g., inventory check, payment processing, shipping notification) happens asynchronously via messaging. -* **Load Leveling (Throttling/Buffering):** - * **Technical Explanation:** A message broker acts as a buffer between fast producers and potentially slower or intermittently available consumers. During peak load, messages can queue up without overwhelming consumers, allowing them to process at their own sustainable rate. This prevents back pressure from propagating upstream, where a slow consumer could otherwise block a fast producer. - * **Impact:** Stabilizes system performance, prevents resource exhaustion in downstream services, and ensures consistent throughput even under fluctuating demand. +* **Load Leveling (Throttling/Buffering):** +** **Technical Explanation:** A message broker acts as a buffer between fast producers and potentially slower or intermittently available consumers. During peak load, messages can queue up without overwhelming consumers, allowing them to process at their own sustainable rate. This prevents back pressure from propagating upstream, where a slow consumer could otherwise block a fast producer. +** **Impact:** Stabilizes system performance, prevents resource exhaustion in downstream services, and ensures consistent throughput even under fluctuating demand. -* **Simplified Integration:** - * **Technical Explanation:** The broker provides a standardized, centralized interface for various applications, potentially written in different languages or running on different platforms, to communicate. This avoids the need for complex, brittle, point-to-point integrations between every service pair, which can become unmanageable in large-scale systems. - * **Impact:** Streamlines the integration of heterogeneous systems and microservices, fostering a more modular, adaptable, and manageable architecture. Different clients using diverse messaging protocols like JMS, AMQP, MQTT, or STOMP (as supported by AMQ Broker) can all communicate seamlessly through the central broker. +* **Simplified Integration:** +** **Technical Explanation:** The broker provides a standardized, centralized interface for various applications, potentially written in different languages or running on different platforms, to communicate. This avoids the need for complex, brittle, point-to-point integrations between every service pair, which can become unmanageable in large-scale systems. +** **Impact:** Streamlines the integration of heterogeneous systems and microservices, fostering a more modular, adaptable, and manageable architecture. Different clients using diverse messaging protocols like JMS, AMQP, MQTT, or STOMP (as supported by AMQ Broker) can all communicate seamlessly through the central broker. === Common Use Cases of Asynchronous Messaging Asynchronous messaging, particularly with a robust broker like Red Hat AMQ Broker, is instrumental in various modern architectural patterns and application scenarios: -* **Event-Driven Architectures (EDA):** - * **Description:** Services communicate by publishing *events* (messages) when something significant happens, and other services *subscribe* to these events to react accordingly. This promotes extreme decoupling and allows services to react autonomously to state changes in the system. - * **Example:** An `OrderPlaced` event published by an `Order Service` could trigger parallel and asynchronous actions in a `Payment Service` (to process payment), an `Inventory Service` (to deduct stock), and a `Notification Service` (to send a confirmation email). +* **Event-Driven Architectures (EDA):** +** **Description:** Services communicate by publishing *events* (messages) when something significant happens, and other services *subscribe* to these events to react accordingly. This promotes extreme decoupling and allows services to react autonomously to state changes in the system. +** **Example:** An `OrderPlaced` event published by an `Order Service` could trigger parallel and asynchronous actions in a `Payment Service` (to process payment), an `Inventory Service` (to deduct stock), and a `Notification Service` (to send a confirmation email). -* **Background Processing / Long-Running Tasks:** - * **Description:** Tasks that are computationally intensive, time-consuming, or require significant external interaction are offloaded from the main application thread to be processed asynchronously by dedicated worker services. - * **Example:** Uploaded image processing (resizing, watermarking), video encoding, generation of large data reports, sending bulk emails, or complex financial calculations can be submitted as messages to a queue and processed by worker services at their own pace. +* **Background Processing / Long-Running Tasks:** +** **Description:** Tasks that are computationally intensive, time-consuming, or require significant external interaction are offloaded from the main application thread to be processed asynchronously by dedicated worker services. +** **Example:** Uploaded image processing (resizing, watermarking), video encoding, generation of large data reports, sending bulk emails, or complex financial calculations can be submitted as messages to a queue and processed by worker services at their own pace. -* **Notifications and Alerts:** - * **Description:** Sending timely notifications to users or other systems in response to specific events, ensuring delivery even if the recipient system is temporarily unavailable. - * **Example:** Transaction confirmations, password reset emails, system alerts (e.g., "CPU utilization exceeded 80%"), or push notifications to mobile devices. The producing service doesn't wait for the notification to be sent. +* **Notifications and Alerts:** +** **Description:** Sending timely notifications to users or other systems in response to specific events, ensuring delivery even if the recipient system is temporarily unavailable. +** **Example:** Transaction confirmations, password reset emails, system alerts (e.g., "CPU utilization exceeded 80%"), or push notifications to mobile devices. The producing service doesn't wait for the notification to be sent. -* **Data Ingestion and Streaming:** - * **Description:** Collecting and processing continuous streams of data from various sources in real-time or near real-time, often acting as a buffer for downstream analytical systems. - * **Example:** IoT device data collection (sensor readings), log aggregation from multiple services, or processing real-time analytics events. AMQ Broker can act as an efficient ingestion point for such data streams before they are persisted or further processed. +* **Data Ingestion and Streaming:** +** **Description:** Collecting and processing continuous streams of data from various sources in real-time or near real-time, often acting as a buffer for downstream analytical systems. +** **Example:** IoT device data collection (sensor readings), log aggregation from multiple services, or processing real-time analytics events. AMQ Broker can act as an efficient ingestion point for such data streams before they are persisted or further processed. -* **Distributed Transactions (Saga Pattern):** - * **Description:** Coordinating a sequence of local transactions across multiple independent services to achieve a single, larger business operation, ensuring eventual consistency. Messages are used to orchestrate the steps, with mechanisms for compensating transactions on failure. - * **Example:** In an e-commerce checkout process, placing an order, deducting payment, and updating inventory are separate microservice actions coordinated via messages. If any step fails, compensating messages can be sent to reverse previous steps (e.g., refund payment, add items back to inventory). +* **Distributed Transactions (Saga Pattern):** +** **Description:** Coordinating a sequence of local transactions across multiple independent services to achieve a single, larger business operation, ensuring eventual consistency. Messages are used to orchestrate the steps, with mechanisms for compensating transactions on failure. +** **Example:** In an e-commerce checkout process, placing an order, deducting payment, and updating inventory are separate microservice actions coordinated via messages. If any step fails, compensating messages can be sent to reverse previous steps (e.g., refund payment, add items back to inventory). -* **Microservices Communication:** - * **Description:** Providing a reliable and scalable communication backbone for microservices to interact without direct, synchronous dependencies, often using queues for point-to-point communication and topics for publish/subscribe patterns. - * **Example:** A `User Service` publishing a `UserRegistered` event, which a `Welcome Email Service` consumes, or a `Product Service` updating product details, which a `Search Indexing Service` consumes to maintain an up-to-date search index. +* **Microservices Communication:** +** **Description:** Providing a reliable and scalable communication backbone for microservices to interact without direct, synchronous dependencies, often using queues for point-to-point communication and topics for publish/subscribe patterns. +** **Example:** A `User Service` publishing a `UserRegistered` event, which a `Welcome Email Service` consumes, or a `Product Service` updating product details, which a `Search Indexing Service` consumes to maintain an up-to-date search index. -* **Batch Processing:** - * **Description:** Processing large volumes of data in batches during off-peak hours or as scheduled jobs. Messages can represent individual items or chunks of data to be processed by a fleet of consumers. - * **Example:** End-of-day financial reconciliation, processing daily reports, or bulk data imports where each record or a small batch of records is a message. +* **Batch Processing:** +** **Description:** Processing large volumes of data in batches during off-peak hours or as scheduled jobs. Messages can represent individual items or chunks of data to be processed by a fleet of consumers. +** **Example:** End-of-day financial reconciliation, processing daily reports, or bulk data imports where each record or a small batch of records is a message. The architectural benefits of asynchronous messaging are profound, allowing for the construction of flexible, robust, and high-performing systems. Understanding these concepts is crucial before diving into the practical deployment and management of Red Hat AMQ Broker on OpenShift, as the broker is the enabling technology for these patterns. Subsequent sections and hands-on labs will demonstrate how AMQ Broker facilitates these use cases through concrete examples of producers and consumers utilizing various messaging protocols. diff --git a/modules/overview-of-message-oriented-middleware/pages/common-messaging-patterns-point-to-point-publishsubscribe.adoc b/modules/overview-of-message-oriented-middleware/pages/common-messaging-patterns-point-to-point-publishsubscribe.adoc index 3f1f420..4246acf 100644 --- a/modules/overview-of-message-oriented-middleware/pages/common-messaging-patterns-point-to-point-publishsubscribe.adoc +++ b/modules/overview-of-message-oriented-middleware/pages/common-messaging-patterns-point-to-point-publishsubscribe.adoc @@ -14,9 +14,9 @@ In a P2P model: * *Queue*: A persistent storage mechanism that holds messages in the order they are received. * *Consumer*: Retrieves messages from the queue. Once a message is consumed, it is removed from the queue. -As per the xref:../../overview/overview-of-message-oriented-middleware.adoc#_queue[product documentation^], a *queue* implements point-to-point semantics: "Each message is seen by only one consumer, and the message is removed from the queue after it is read." +As per the xref:../../overview/overview-of-message-oriented-middleware.adoc#_queue[product documentation], a *queue* implements point-to-point semantics: "Each message is seen by only one consumer, and the message is removed from the queue after it is read." -Key characteristics of Point-to-Point messaging: +*Key characteristics of Point-to-Point messaging:* * *Single Consumer*: Regardless of how many consumers are listening to a queue, each message is delivered to only one of them. * *Message Removal*: After a consumer successfully processes a message, the message is removed from the queue, ensuring it's not processed again by another consumer. diff --git a/modules/overview-of-message-oriented-middleware/pages/core-concepts-producers-consumers-queues-topics.adoc b/modules/overview-of-message-oriented-middleware/pages/core-concepts-producers-consumers-queues-topics.adoc index d72e89e..56abbb2 100644 --- a/modules/overview-of-message-oriented-middleware/pages/core-concepts-producers-consumers-queues-topics.adoc +++ b/modules/overview-of-message-oriented-middleware/pages/core-concepts-producers-consumers-queues-topics.adoc @@ -51,7 +51,8 @@ A xref:amq-broker-on-openshift::overview.adoc#_queue[queue] implements *point-to * **Ordering:** Messages are typically processed in the order they were received (FIFO - First-In, First-Out). [EXAMPLE] -.Point-to-Point Messaging with Queues +.*Point-to-Point Messaging with Queues* + Imagine an online order processing system. Each new order is placed into an `OrderQueue`. Multiple worker processes (consumers) can listen to this queue. When an order arrives, one worker picks it up for processing. The message is then removed from the queue, preventing duplicate processing by other workers. === Topics (Publish-Subscribe Messaging) diff --git a/modules/overview-of-message-oriented-middleware/pages/overview-of-message-oriented-middleware.adoc b/modules/overview-of-message-oriented-middleware/pages/overview-of-message-oriented-middleware.adoc index 2da1557..4d89fd5 100644 --- a/modules/overview-of-message-oriented-middleware/pages/overview-of-message-oriented-middleware.adoc +++ b/modules/overview-of-message-oriented-middleware/pages/overview-of-message-oriented-middleware.adoc @@ -1,6 +1,5 @@ # Overview of Message-Oriented Middleware -=== Overview of Message-Oriented Middleware Message-Oriented Middleware (MOM) is a software layer that enables communication between distributed applications by sending and receiving messages. It facilitates asynchronous messaging, decoupling senders (producers) from receivers (consumers). diff --git a/modules/scaling-amq-broker-on-openshift/pages/adjusting-resource-allocations-cpu-memory-for-broker-pods.adoc b/modules/scaling-amq-broker-on-openshift/pages/adjusting-resource-allocations-cpu-memory-for-broker-pods.adoc index 1731c07..274cc1a 100644 --- a/modules/scaling-amq-broker-on-openshift/pages/adjusting-resource-allocations-cpu-memory-for-broker-pods.adoc +++ b/modules/scaling-amq-broker-on-openshift/pages/adjusting-resource-allocations-cpu-memory-for-broker-pods.adoc @@ -1,6 +1,5 @@ # Adjusting Resource Allocations (CPU, Memory) for Broker Pods -= Adjusting Resource Allocations (CPU, Memory) for Broker Pods This section details how to configure CPU and memory resource allocations for your AMQ Broker pods deployed on OpenShift. Properly setting these values is crucial for ensuring stable performance, efficient resource utilization, and predictable behavior of your messaging infrastructure. diff --git a/modules/scaling-amq-broker-on-openshift/pages/performance-considerations-for-scaling.adoc b/modules/scaling-amq-broker-on-openshift/pages/performance-considerations-for-scaling.adoc index 22ac223..2c78c64 100644 --- a/modules/scaling-amq-broker-on-openshift/pages/performance-considerations-for-scaling.adoc +++ b/modules/scaling-amq-broker-on-openshift/pages/performance-considerations-for-scaling.adoc @@ -1,6 +1,5 @@ # Performance Considerations for Scaling -= Performance Considerations for Scaling AMQ Broker on OpenShift When scaling your Red Hat AMQ Broker deployment on OpenShift, it's not just about adding more pods or increasing their count; it's crucially about ensuring each pod has the right resources to perform optimally. Misconfigured resource allocations can lead to performance bottlenecks, instability, or inefficient use of your OpenShift cluster, directly impacting message throughput, latency, and overall system reliability. This section delves into the key performance considerations related to resource management when scaling AMQ Broker instances. diff --git a/modules/scaling-amq-broker-on-openshift/pages/scaling-amq-broker-on-openshift.adoc b/modules/scaling-amq-broker-on-openshift/pages/scaling-amq-broker-on-openshift.adoc index 6c975eb..13a1b04 100644 --- a/modules/scaling-amq-broker-on-openshift/pages/scaling-amq-broker-on-openshift.adoc +++ b/modules/scaling-amq-broker-on-openshift/pages/scaling-amq-broker-on-openshift.adoc @@ -1,6 +1,5 @@ # Scaling AMQ Broker on OpenShift -=== Scaling AMQ Broker on OpenShift Scaling AMQ Broker on OpenShift involves adjusting its capacity to handle varying message loads. This includes: diff --git a/modules/securing-amq-broker-on-openshift/pages/encrypting-connections.adoc b/modules/securing-amq-broker-on-openshift/pages/encrypting-connections.adoc index 85de39b..2ce4983 100644 --- a/modules/securing-amq-broker-on-openshift/pages/encrypting-connections.adoc +++ b/modules/securing-amq-broker-on-openshift/pages/encrypting-connections.adoc @@ -1,6 +1,5 @@ # Encrypting Connections -= Encrypting Connections for AMQ Broker on OpenShift This section details how to secure client-broker communication for Red Hat AMQ Broker deployed on OpenShift using Transport Layer Security (TLS). Encrypting connections is a fundamental security measure, ensuring the confidentiality and integrity of messages exchanged between clients and the broker. diff --git a/modules/securing-amq-broker-on-openshift/pages/integrating-external-identity-providers-idp.adoc b/modules/securing-amq-broker-on-openshift/pages/integrating-external-identity-providers-idp.adoc index 8db4307..934c25c 100644 --- a/modules/securing-amq-broker-on-openshift/pages/integrating-external-identity-providers-idp.adoc +++ b/modules/securing-amq-broker-on-openshift/pages/integrating-external-identity-providers-idp.adoc @@ -1,6 +1,5 @@ # Integrating External Identity Providers (IDP) -= Integrating External Identity Providers (IDP) This section delves into integrating Red Hat AMQ Broker on OpenShift with external Identity Providers (IDP). This capability is crucial for organizations that need to centralize user management and leverage existing authentication systems for their messaging infrastructure. diff --git a/modules/securing-amq-broker-on-openshift/pages/managing-certificates-and-trust-stores-on-openshift.adoc b/modules/securing-amq-broker-on-openshift/pages/managing-certificates-and-trust-stores-on-openshift.adoc index 0010476..2075a3f 100644 --- a/modules/securing-amq-broker-on-openshift/pages/managing-certificates-and-trust-stores-on-openshift.adoc +++ b/modules/securing-amq-broker-on-openshift/pages/managing-certificates-and-trust-stores-on-openshift.adoc @@ -1,7 +1,5 @@ # Managing Certificates and Trust Stores on OpenShift -= Managing Certificates and Trust Stores on OpenShift -include::partial$attributes.adoc[] _A technical deep dive into securing Red Hat AMQ Broker deployments on OpenShift by effectively managing TLS certificates and trust stores._