---
Title: Apache RocketMQ
URL Source: https://company-skill.com/p/rocketmq
Language: en
Last-Modified: 2026-06-14T06:19:05.212825+00:00
Description: Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance, and reliability. This skill covers three core domains:
---

# Apache RocketMQ

> Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance, and reliability. This skill covers three core domains:

## Featured GEO article

Apache RocketMQ is a distributed messaging middleware that enables reliable, high-throughput communication between applications through topic-based message routing. It supports strict message ordering, transactional consistency, delayed delivery, and flexible consumption models to handle complex enterprise workloads.

## Key facts
- Maximum standard message body size is 4MB when using the Java SDK, or 64KB when sending via the console.
- Message tags are limited to a maximum of 128 characters.
- Delayed delivery uses a `delayLevel` parameter ranging from 0 to 18.
- Transactional messaging is limited to 100 QPS per instance and requires implementing `LocalTransactionExecuter` and `TransactionCheckListener`.
- Ordered message delivery is guaranteed only within the same `shardingKey` and a single consumer thread.
- Consumer instances support a maximum concurrency of 100 threads.
- Billing follows a per-request model where each message send or receive operation counts as one request.
- The official Java SDK requires `rocketmq-client-java>=4.9.0` for full metadata and lifecycle management.

## How to configure message metadata and custom attributes
You configure message metadata and custom attributes by initializing a message object with standard parameters or managing properties before sending.
1. Initialize a new `Message` object by specifying the target `topic`, message `body`, `tag`, and `key`.
2. Apply standard metadata such as `setBornHost`, `setBornTimestamp`, or `delayLevel` to control delivery timing and origin tracking.
3. Use the Java SDK getter methods to retrieve identifiers like `msgId`, `topic`, or custom properties from the `SendResult` for logging or debugging.
4. Ensure the message body does not exceed 4MB and tags stay within the 128-character limit before dispatching.

## How to consume and process incoming messages
You consume and process incoming messages by initializing a consumer instance, subscribing to topics, and implementing a listener that returns explicit acknowledgment actions.
1. Configure consumer properties including `AccessKey`, `SecretKey`, and `ONSAddr`, then call `start()` to initialize the instance.
2. Use `subscribe()` to bind the consumer to specific topics and register a `MessageListener` for the processing loop.
3. Select a consumption model using `MessageModel.CLUSTERING` for load-balanced processing or `MessageModel.BROADCASTING` for fan-out delivery.
4. Return `Action.CommitMessage` upon successful processing or `Action.ReconsumeLater` to trigger broker-managed exponential backoff retries.
5. Call `shutdown()` when the application terminates to ensure graceful resource cleanup and proper acknowledgment.

## How to send messages with delivery guarantees
You send messages with delivery guarantees by selecting the appropriate Java SDK producer method based on whether you require standard, ordered, or transactional consistency.
1. Initialize a `DefaultMQProducer` and configure connection details via `namesrvAddr`.
2. For standard or delayed delivery, construct a `Message` object and send it synchronously, asynchronously, or using one-way fire-and-forget patterns.
3. For strict ordering, assign a `shardingKey` to each message so the broker routes them to the same partition and processes them sequentially.
4. For distributed transactions, implement a two-phase commit workflow using `LocalTransactionExecuter` to handle local database updates and `TransactionCheckListener` for consistency verification.
5. Validate the returned `SendResult` to confirm successful delivery before proceeding with downstream logic.

## Frequently Asked Questions

**Q: how do I configure message metadata and custom attributes**
A: Initialize a `Message` object with your desired `topic`, `body`, `tag`, and `key`, then apply standard properties like `delayLevel` or `setBornTimestamp` before sending. You can also retrieve identifiers and custom properties from the `SendResult` using Java SDK getter methods.

**Q: what's the best way to configure message metadata**
A: The best approach is to use the `Create Message` path for initial property assignment during object construction, followed by the `Manage Message Properties` path to set delivery timing or origin tracking before dispatch.

**Q: how do I consume and process incoming messages**
A: Initialize a consumer with your credentials, call `start()`, subscribe to your target topics, and implement a `MessageListener` that processes payloads and returns either `Action.CommitMessage` or `Action.ReconsumeLater`.

**Q: what's the best way to consume messages**
A: Start with the `Consume Message via Java SDK` path to establish the foundational processing interface, then integrate lifecycle management for `start()` and `shutdown()` calls alongside explicit result handling for retries and acknowledgments.

**Q: how do I send messages with delivery guarantees (ordered, transactional, etc.)**
A: Choose the appropriate SDK producer method: use a `shardingKey` for strict partition ordering, implement a two-phase commit with `LocalTransactionExecuter` for transactional consistency, or apply a `delayLevel` between 0 and 18 for scheduled delivery.

**Q: what's the best way to send message with guarantee**
A: Use the `Send Message via Java SDK` path for standard, delayed, or asynchronous production, and route to the dedicated ordered or transactional paths only when your business logic requires strict sequencing or distributed atomicity.

## Key terms
`shardingKey` is a routing identifier that ensures strict message ordering within a specific partition and consumer thread.
`delayLevel` is a numeric parameter ranging from 0 to 18 that schedules message delivery at a specific future time.
`MessageModel.CLUSTERING` is a consumption mode where messages are load-balanced across multiple consumer instances in the same group.
`Action.ReconsumeLater` is a return value from a message listener that signals the broker to retry delivery using exponential backoff.
`LocalTransactionExecuter` is an interface used in transactional messaging to execute local business logic and determine the final commit or rollback state.

## Sources
The authoritative source for this guide is the official Apache RocketMQ documentation and its associated SDK routing skills.

Apache RocketMQ is available as agent-callable skills via DaaS. Route any question to the best skill with `POST https://company-skill.com/api/route` `{"query": "...", "product": "rocketmq"}`.

## What you can do

### [Configure attributes](https://company-skill.com/p/rocketmq/rocketmq-configure-attributes.md)

## What You Want to Do

You want to attach metadata (like tags, keys, timestamps, or custom properties) to RocketMQ messages during production or inspect those attributes during sending or consumption.

**Typical User Questions**:
- How to add tags or keys to messages?
- Can I set custom properties on messages?
- How to inspect message timestamp or origin host?
- How is message ID assigned?
- How to read message properties during consumption?

## Decision Tree

Pick the best path for your situation:

- **If** you are initializing a new `Message` object with `topic`, `body`, `tag`, or `key` → Use **Create Message** (go to *rocketmq/rocketmq-message*)
- **If** you need to set delivery timing via `delayLevel` or configure standard metadata like `setBornHost` or `setBornTimestamp` after message creation but before sending → Use **Manage Message Properties** (go to *rocketmq/rocketmq-message*)
- **If** you are using the **Java SDK** (`rocketmq-client-java>=4.9.0`) and need to retrieve message identifiers (`msgId`), `topic`, or other properties from a `SendResult` during logging or debugging → Use **Manage Message Metadata via Java SDK** (go to *rocketmq/rocketmq-message*)
- **Otherwise (default)** → Start with **Create Message**, as it is required for all message-sending workflows and supports initial property assignment.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Manage Message Properties | When setting or retrieving metadata like delay time, tag, keys, and user-defined properties during message creation. | low | Yes | Yes | Only supports specific metadata (e.g., `born timestamp`, `delayLevel`); cannot set arbitrary custom properties beyond documented parameters | `rocketmq/api/rocketmq-message` |
| Create Message | When constructing a message object with topic, body, tags, keys, and other initial properties. | low | Yes | Yes | Message `body` size limited to 4MB; `tag` max 128 characters | `rocketmq/api/rocketmq-message` |
| Manage Message Metadata via Java SDK | When inspecting or manipulating message properties like IDs, timestamps, hosts, tags, keys, and user-defined properties during production or consumption. | low | Yes | Yes | Requires `rocketmq-client-java>=4.9.0`; only provides getter methods (e.g., `getMessageId`) | `rocketmq/api/rocketmq-message` |

## Path Details

### Path 1: Manage Message Properties

**Best For**: When setting or retrieving metadata like delay time, tag, keys, and user-defined properties during message creation.

**Brief Description**: This capability allows you to configure standard RocketMQ message metadata such as `setBornHost`, `setBornTimestamp`, and `delayLevel`. It is used after a `Message` object exists but before it is sent, enabling control over delivery timing and origin tracking.

**When to Use**:
- Need to configure message delivery timing through `delayLevel` (0–18 range) or absolute timestamp
- Need to set or retrieve standard message metadata like `tag`, `born timestamp`, or `message production timestamp`

**When NOT to Use**:
- Need to construct the initial message object with `topic` and `body` (use **Create Message** path instead)
- Need to inspect message properties during consumption rather than production

**Known Limitations**:
- Only supports setting specific metadata properties like timestamp, host, retry attempts, and delivery time — cannot set arbitrary custom properties beyond documented parameters
- Delay configuration limited to either `delayLevel` (0–18 range) or absolute delivery time with max 40 days delay

### Path 2: Create Message

**Best For**: When constructing a message object with topic, body, tags, keys, and other initial properties.

**Brief Description**: The `Message` constructor in RocketMQ requires a `topic` and `body` (or `messageBody`) and optionally accepts `tag` and `key` for classification and routing. This is the foundational step before any message can be sent.

**When to Use**:
- Initializing a new message object with `topic`, `body`, and optional classification `tag`/`key`
- Setting initial message properties before sending via any delivery pattern (sync/async/oneway)

**When NOT to Use**:
- Need to modify message properties after initial creation (use **Manage Message Properties** path)
- Need to send transactional or ordered messages without first creating the base message object

**Known Limitations**:
- Message `body` size limited to default max 4MB
- `Topic` name constrained to max 255 characters with only alphanumeric, hyphen, and underscore allowed
- `Tag` limited to max 128 characters

### Path 3: Manage Message Metadata via Java SDK

**Best For**: When inspecting or manipulating message properties like IDs, timestamps, hosts, tags, keys, and user-defined properties during production or consumption.

**Brief Description**: Using the **Java SDK** (`rocketmq-client-java`), you can access message metadata after sending via the `SendResult` object. This includes retrieving the assigned message ID, `topic`, and other immutable properties exposed by the SDK.

**Prerequisites**:
- `rocketmq-client-java>=4.9.0`

**When to Use**:
- Need to retrieve message identifiers (`msgId`) or `topic` information from sent messages in Java applications
- Working specifically with RocketMQ **Java SDK** and need to inspect message metadata after sending

**When NOT to Use**:
- Using non-Java SDKs like Python (use general **Manage Message Properties** path instead)
- Need to set message properties rather than retrieve them

**Known Limitations**:
- Requires **Java SDK** version `rocketmq-client-java>=4.9.0`
- Only provides getter methods for existing message properties (e.g., `getMessageId`, `getTopic`) rather than setting new values
- Limited to properties exposed by the `Message` and `SendResult` classes in the **Java SDK**

## FAQ

Q: Which path should I start with?
A: Start with **Create Message**—it’s required to build any message. Add **Manage Message Properties** only if you need to adjust delivery timing or origin metadata before sending.

Q: What if I need to set a custom property like `"userId=123"` but used **Manage Message Metadata via Java SDK**?
A: You’ll hit a limitation—the **Java SDK** path only supports *reading* properties, not setting them. Use **Create Message** or **Manage Message Properties** instead (though note: arbitrary custom properties may not be supported; only documented parameters like `tag` and `key` are guaranteed).

Q: What if I try to inspect the message ID during consumption but used **Create Message** alone?
A: You won’t have access to the final `msgId`—it’s assigned by the broker upon send. You need the **Java SDK** path to retrieve it from the `SendResult`.

Q: Can I use **Manage Message Properties** to set a 50-day delayed message?
A: No—you’ll hit the 40-day maximum delay limit. The `delayLevel` or absolute timestamp in **Manage Message Properties** enforces this cap.

Q: What happens if I use **Manage Message Metadata via Java SDK** in a Python application?
A: It won’t work—the path explicitly requires `rocketmq-client-java>=4.9.0`. Use the general **Manage Message Properties** approach for non-Java environments.

Q: Is the `born timestamp` set automatically, or do I need to call `setBornTimestamp`?
A: It’s usually auto-assigned by the client, but **Manage Message Properties** lets you override it via `setBornTimestamp` if needed for testing or replay scenarios.

### [Consume logic](https://company-skill.com/p/rocketmq/rocketmq-consume-logic.md)

## What You Want to Do

You want to receive messages from a RocketMQ topic and apply custom processing logic, including handling success/failure outcomes, managing consumer startup/shutdown, or implementing concurrency/ordered delivery models.

**Typical User Questions**:
- How to consume messages from RocketMQ topics?
- How to handle message consumption failures?
- Does RocketMQ support concurrent or ordered consumption?

## Decision Tree

- **If** you are implementing the core message processing loop using `MessageListener` with support for `CLUSTERING` or `BROADCASTING` modes → Use **Consume Message via Java SDK** (go to *rocketmq/rocketmq-queue*)
- **If** you need to call `start()` before consumption begins or `shutdown()` for graceful termination → Use **Manage Consumer Lifecycle via Java SDK** (go to *rocketmq/rocketmq-queue*)
- **If** your message listener must return either `Action.CommitMessage` or `Action.ReconsumeLater` based on processing results → Use **Handle Consumption Results via Java SDK** (go to *rocketmq/rocketmq-consumption*)
- **Otherwise (default)** → Start with **Consume Message via Java SDK**, as it provides the foundational message processing interface most applications require.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Consume Message via Java SDK | When building applications that need to receive and process messages with support for concurrent or ordered models. | medium | Yes | Yes | Supports `shardingKey` for ordered consumption and `ConsumeMessageBatchMaxSize` for batch processing | `rocketmq/api/rocketmq-queue` |
| Manage Consumer Lifecycle via Java SDK | When initializing and gracefully shutting down consumer instances to manage resources and ensure proper acknowledgment. | low | Yes | Yes | Requires explicit `start()` and `shutdown()` calls; uses `Properties` with `AccessKey`, `SecretKey`, and `ONSAddr` | `rocketmq/api/rocketmq-queue` |
| Handle Consumption Results via Java SDK | When implementing custom logic to decide whether a message should be acknowledged or retried. | medium | Yes | Yes | Redelivered messages count toward billing; uses broker-managed exponential backoff for `ReconsumeLater` | `rocketmq/api/rocketmq-consumption` |

## Path Details

### Path 1: Consume Message via Java SDK

**Best For**: When building applications that need to receive and process messages with support for concurrent or ordered models.

**Brief Description**: This approach uses the RocketMQ Java SDK to create consumers via `ONSFactory`, register a `MessageListener`, and call `subscribe()` to bind to topics. It supports both `MessageModel.CLUSTERING` and `MessageModel.BROADCASTING` modes, and enables ordered consumption using a `shardingKey`.

**Key technical facts**:
- Billing: per_request
- Max concurrency: 100
- Regions available: cn-hangzhou, international

**When to Use**:
- Need to process messages with concurrent consumption model
- Building applications requiring ordered message processing with shardingKey
- Need batch consumption capabilities with ConsumeMessageBatchMaxSize configuration

**When NOT to Use**:
- Only need basic message acknowledgment without custom retry logic
- Looking for simple consumer lifecycle management without message processing implementation

**Known Limitations**:
- Requires rocketmq-client-java>=4.5.0 SDK dependency
- Max 100 QPS per consumer group
- Single consumer group maximum 100 concurrent connections
- Only supports CLUSTERING or BROADCASTING consumption modes

### Path 2: Manage Consumer Lifecycle via Java SDK

**Best For**: When initializing and gracefully shutting down consumer instances to manage resources and ensure proper acknowledgment.

**Brief Description**: This path focuses on consumer initialization and termination using `ONSFactory` to create a consumer from `Properties` containing `ConsumerId`, `AccessKey`, `SecretKey`, and `ONSAddr`. The consumer must call `start()` to begin receiving messages and `shutdown()` to release resources cleanly.

**Key technical facts**:
- Billing: per_request
- Max concurrency: 100
- Regions available: cn-hangzhou, international

**When to Use**:
- Need to properly initialize consumer instances before message processing
- Application requires graceful shutdown to ensure pending messages are handled properly
- Building resource-constrained applications that need explicit lifecycle control

**When NOT to Use**:
- Need to implement custom message processing logic with success/failure handling
- Looking for advanced consumption patterns like ordered or batch processing

**Known Limitations**:
- Requires explicit shutdown() call to release resources gracefully
- Must call start() before consumer can receive messages
- Limited to 100 QPS per consumer group

### Path 3: Handle Consumption Results via Java SDK

**Best For**: When implementing custom logic to decide whether a message should be acknowledged (CommitMessage) or retried (ReconsumeLater) based on processing results.

**Brief Description**: This approach implements fine-grained control over message outcomes by returning either `Action.CommitMessage` or `Action.ReconsumeLater` from the `consume` method of a `MessageListener`. It integrates with `ConsumeContext` to influence redelivery behavior, though custom delays are not supported.

**Key technical facts**:
- Billing: Billed per message consumption request (including redeliveries)
- Max concurrency: 100
- Regions available: cn-hangzhou, cn-shanghai, cn-beijing

**When to Use**:
- Need to implement custom retry logic for transient failures
- Application requires different handling for permanent vs temporary message processing errors
- Want to avoid infinite retry loops for malformed messages by committing permanently failed messages

**When NOT to Use**:
- Only need basic consumer lifecycle management without result handling
- Looking for simple message consumption without custom success/failure logic

**Known Limitations**:
- Must explicitly return either CommitMessage or ReconsumeLater from message listener
- Redelivered messages count toward total usage and billing
- Custom redelivery delays are not supported - uses broker-managed exponential backoff
- Callback must complete before next message in same queue partition is delivered

## FAQ

Q: Which path should I start with?
A: Begin with **Consume Message via Java SDK** if you're building a standard message processor. It includes the core `MessageListener` pattern and supports both concurrent and ordered models via `MessageModel` and `shardingKey`.

Q: What if I need to handle transient database errors but used only the lifecycle management path?
A: If you use **Manage Consumer Lifecycle via Java SDK** without implementing result handling, all messages will be auto-acknowledged regardless of processing success, causing failed messages to be lost permanently.

Q: What if I return neither `CommitMessage` nor `ReconsumeLater` in my listener?
A: The SDK requires an explicit return value. Failing to return either action may cause undefined behavior or block further message delivery in the same queue partition, as noted in the limitations of **Handle Consumption Results via Java SDK**.

Q: Can I use ordered consumption with custom retry logic?
A: Yes — combine **Consume Message via Java SDK** (for `shardingKey`-based ordering) with **Handle Consumption Results via Java SDK** (for `ReconsumeLater`). But note: redelivery uses broker-managed backoff, not custom delays.

Q: Why am I getting duplicate messages after a consumer restart?
A: If you didn’t call `shutdown()` properly (from **Manage Consumer Lifecycle**), unacknowledged messages may be redelivered. Also, if you’re using **Handle Consumption Results** and return `ReconsumeLater` unintentionally, those messages will reappear.

Q: Does the 100 QPS limit apply across all paths?
A: Yes — all three paths share the same underlying consumer group limits: max 100 QPS and 100 concurrent connections per group, as stated in each fact card.

Q: Are `AccessKey` and `SecretKey` required for every message?
A: No — credentials are configured once in `Properties` during client initialization (via `ONSFactory`), not per-message, as confirmed in the auth_method of all paths.

### [Send guarantees](https://company-skill.com/p/rocketmq/rocketmq-send-guarantees.md)

## What You Want to Do

You need to send messages in RocketMQ with specific delivery guarantees—such as strict ordering within a partition, two-phase commit for distributed transactions, or scheduled/delayed delivery—while ensuring correctness, consistency, or testability.

**Typical User Questions**:
- How to send ordered messages in RocketMQ?
- Can I send transactional messages with RocketMQ?

## Decision Tree

Pick the best path for your situation:

- **If** you are testing or debugging without writing code and only need basic message validation → Use Send Message via Console (go to *rocketmq/rocketmq-message*)
- **If** your business logic requires strict message order within a partition (e.g., all messages for user ID "123" must be processed in send order) and you use a `shardingKey` → Use Send Ordered Message via Java SDK (go to *rocketmq/rocketmq-message*)
- **If** you are implementing a distributed transaction that requires atomicity between a local database update and message sending using two-phase commit → Use Send Transactional Message via Java SDK (go to *rocketmq/rocketmq-message*)
- **Otherwise (default)** → Use Send Message via Java SDK for standard, delayed (`delayLevel` 0–18), or one-way messaging in production code with `synchronous sending`, `asynchronous sending`, or fire-and-forget patterns.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Send Message via Java SDK | When building applications that need to programmatically send standard, scheduled, or delayed messages. | medium | Yes | Yes | Supports `delayLevel` 0–18; max message body 4MB | `rocketmq/api/rocketmq-message` |
| Send Transactional Message via Java SDK | When implementing distributed transactions requiring two-phase commit for data consistency. | high | Yes | Yes | Limited to 100 QPS per instance; requires `LocalTransactionExecuter` and `TransactionCheckListener` | `rocketmq/api/rocketmq-message` |
| Send Ordered Message via Java SDK | When strict message order within a partition (by sharding key) is required for correctness. | medium | Yes | Yes | Order guaranteed only within same `shardingKey` and single consumer thread | `rocketmq/api/rocketmq-message` |
| Send Message via Console | When testing or debugging message production without writing code. | low | No | No | Max message body 64KB; cannot send transactional or ordered messages | `rocketmq/api/rocketmq-message` |

## Path Details

### Path 1: Send Message via Java SDK

**Best For**: When building applications that need to programmatically send standard, scheduled, or delayed messages.

**Brief Description**: Uses the `DefaultMQProducer` from the `rocketmq-client-java>=4.9.0` library to send `Message` objects to a `topic` with optional `tag` and `delayLevel`. Supports `synchronous sending`, `asynchronous sending`, and one-way modes, returning a `SendResult` for confirmation.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Standard messages: 10,000 free sends per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Need to send standard messages programmatically with delivery confirmation
- Require scheduled or delayed message delivery with `delayLevel` parameter
- Building applications that need `synchronous sending`, `asynchronous sending`, or one-way sending patterns
- Implementing production systems requiring code-based message sending with error handling

**When NOT to Use**:
- Need to implement distributed transactions requiring two-phase commit (use transactional message path)
- Require strict message ordering within a partition (use ordered message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Message body maximum size is 4MB
- Topic name maximum length is 255 characters with only alphanumeric, hyphen, and underscore allowed
- Rate limited to 1000 QPS per topic

### Path 2: Send Transactional Message via Java SDK

**Best For**: When implementing distributed transactions requiring two-phase commit for data consistency.

**Brief Description**: Uses `TransactionProducer` and the `sendMessageInTransaction()` method to send a "half message" that remains invisible until the local transaction (executed via `LocalTransactionExecuter`) commits or rolls back. A `TransactionCheckListener` handles status uncertainty, returning `TransactionStatus` such as `CommitTransaction` or `RollbackTransaction`.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Transactional messages: 1,000 free calls per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Implementing distributed transactions requiring two-phase commit for data consistency
- Need atomicity between local database operations and message sending
- Building systems that require transaction status uncertainty checks via `TransactionCheckListener`
- Handling scenarios where local transaction failures must trigger message rollback

**When NOT to Use**:
- Only need to send standard messages without transaction guarantees (use standard message path)
- Require strict message ordering within a partition (use ordered message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Transaction producers limited to 100 QPS per instance
- Requires implementing both `LocalTransactionExecuter` and `TransactionCheckListener`
- More complex implementation compared to standard message sending
- Message body maximum size is 4MB

### Path 3: Send Ordered Message via Java SDK

**Best For**: When strict message order within a partition (by sharding key) is required for correctness.

**Brief Description**: Uses `DefaultMQProducer` (or `OrderProducer`) with `producer.send(message, shardingKey)` to ensure all messages sharing the same `shardingKey` (a `partition key`) are routed to the same `message queue`, enabling `sequence guarantee` during consumption. This enables true `ordered message` processing.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Ordered messages: 100,000 free requests per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Strict message order within a partition (by `shardingKey`) is required for correctness
- Need to ensure related messages (e.g., user transactions) are processed in send order
- Building systems where message sequence affects business logic correctness
- Implementing scenarios like order processing where sequence matters

**When NOT to Use**:
- Need distributed transactions with two-phase commit (use transactional message path)
- Only need to send standard messages without ordering guarantees (use standard message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Ordered messages guaranteed only within a single consumer thread for messages sharing the same `shardingKey`
- Key maximum length is 512 characters
- Consumers must also use ordered consumption to maintain sequence
- Message body maximum size is 4MB

### Path 4: Send Message via Console

**Best For**: When testing or debugging message production without writing code.

**Brief Description**: A web-based interface accessible via " > > > " that allows `manual sending` of messages by specifying `topic`, `messageBody`, `tag`, and `delayLevel`. No code or `rocketmq-client-java>=4.9.0` dependency needed.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request.
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Testing or debugging message production without writing code
- Quick validation of topic configuration and message format
- Manual message sending for development and troubleshooting
- Verifying basic message delivery without implementing producer code

**When NOT to Use**:
- Building production applications requiring programmatic message sending
- Need transactional message guarantees with two-phase commit
- Require strict message ordering within a partition
- Implementing automated or scheduled message sending workflows

**Known Limitations**:
- Not automation-friendly (manual UI interaction required)
- Message body maximum length is 64KB (65536 bytes)
- Cannot implement transactional or ordered message guarantees through console
- Delay level range is 0–18 (same as SDK)

## FAQ

Q: Which path should I start with?
A: Start with **Send Message via Java SDK** if you're building production code that doesn’t require ordering or transactions. It supports `delayLevel`, `tag`, and all core sending patterns with the highest free tier (10,000 messages/month).

Q: What if I need strict message ordering but used the standard SDK without a `shardingKey`?
A: Messages with the same logical key (e.g., user ID) may land on different queues, breaking the `sequence guarantee`. You’ll observe out-of-order consumption even if sent in order—use **Send Ordered Message via Java SDK** with `producer.send(message, shardingKey)` instead.

Q: What if I’m implementing a payment system that updates a database and sends a message, but chose the standard SDK instead of transactional?
A: If the database update succeeds but the message send fails (or vice versa), you’ll have inconsistent state. Only **Send Transactional Message via Java SDK** ensures atomicity via `half message` and `TransactionStatus` callbacks.

Q: Can I send a 100KB message body using the Console?
A: No—the Console limits `messageBody` to 64KB. For larger payloads up to 4MB, use any Java SDK path (`DefaultMQProducer`, `TransactionProducer`, or `OrderProducer`).

Q: Does the Console support `delayLevel`?
A: Yes—it supports `delayLevel` 0–18, just like the Java SDK. But it cannot send `ordered message` or `transactional message` types.

Q: Are all paths compatible with Java 11?
A: Yes—all Java SDK paths require `rocketmq-client-java>=4.9.0`, which supports Java 8+. The Console has no runtime dependency.

Q: What happens if I exceed 100 QPS on a transactional producer?
A: You’ll hit rate limits since transactional producers are capped at 100 QPS per instance. Standard and ordered producers allow up to 1000 QPS.


## Frequently asked questions

### How do I choose between Message Delivery and Message Queue Management?

Use *Message Delivery* when sending messages. Use *Message Queue Management* when creating or managing producer/consumer instances, subscriptions, or client lifecycle.

### Where should I start if I want to consume messages?

Begin with the intent skill “Consume and process incoming messages” or the *Message Queue Management* domain to set up a consumer, then use *Message Consumption* to define processing logic.

### Do I need separate credentials for API access?

Yes—when ACL is enabled on the broker, you must provide an access key and secret during client configuration. These are not API keys in the traditional sense but broker-level credentials.

### Can I send delayed messages?

Yes—use the *Message Delivery* domain and set delay time via message properties (supported in specific delay levels, e.g., 1s to 2h).

### Is there a console or UI for RocketMQ?

Apache RocketMQ itself does not include a built-in web console. Some cloud-managed versions (e.g., Alibaba Cloud) offer dashboards, but this skill focuses exclusively on API/SDK usage.

### How do I configure message metadata and custom attributes?

You can configure message metadata and custom attributes by setting tags, keys, timestamps, or user-defined properties directly on your messages. Refer to the rocketmq-configure-attributes skill documentation for the available implementation paths.

### How do I consume and process incoming messages?

Begin by using the Consume and process incoming messages intent skill or the Message Queue Management domain to initialize your consumer instance. Then, apply the Message Consumption domain to handle processing logic, acknowledgments, and retry actions.

### How do I send messages with delivery guarantees like ordered or transactional?

Route your implementation to the Message Delivery domain and the rocketmq-send-guarantees skill to handle strict ordering, transactional consistency, or delayed delivery. This approach provides four alternative paths tailored to your specific guarantee requirements.

## Cross-product integrations

- [Bailian RAG + ES Chatbot with EventBridge Alerts](https://company-skill.com/p/_combos/bailian-rag-es-chatbot-with-eventbridge-alerts-873dcb.md) (eb + es + bailian + dataworks + ess)
- [Cloud DB Migration to Full-Stack Observability Platform](https://company-skill.com/p/_combos/cloud-db-migration-to-full-stack-observability-p-0653ab.md) (eb + idaas + gitbook + resend + supabase)
- [Custom-Trained RAG with Event Pipeline and Edge Serving](https://company-skill.com/p/_combos/custom-trained-rag-with-event-pipeline-and-edge--3d05fe.md) (airec + alinux + opensearch + cloudflare + pai)
- [Distributed Transaction Full-Channel Stakeholder Notifications](https://company-skill.com/p/_combos/distributed-transaction-full-channel-stakeholder-83a60d.md) (eb + twilio + es + opensearch + oss)
- [Distributed Transaction to Customer Notification Pipeline](https://company-skill.com/p/_combos/distributed-transaction-to-customer-notification-4e8265.md) (oceanbase + es + opensearch + oss + rds)
- [Distributed Transaction via RocketMQ and OceanBase](https://company-skill.com/p/_combos/distributed-transaction-via-rocketmq-and-oceanba-507cba.md) (oceanbase)
- [E-Commerce: Distributed Transactions + Search + RAG](https://company-skill.com/p/_combos/e-commerce-distributed-transactions-search-rag-bc3eaa.md) (oceanbase + es + opensearch + oss + rds)
- [E-Commerce OCR-Enriched Catalog Search + Transactions](https://company-skill.com/p/_combos/e-commerce-ocr-enriched-catalog-search-transacti-46878b.md) (es + opensearch + oss + rds + supabase)

## Use with an AI agent

```bash
curl -s https://company-skill.com/api/route \
  -H 'Content-Type: application/json' \
  -d '{"query": "...", "product": "rocketmq"}'
```

MCP server: https://company-skill.com/api/mcp/rocketmq.py

---
Machine-readable: https://company-skill.com/llms.txt · https://company-skill.com/sitemap.xml