camel.apache.org/spring-rabbitmq
1
0
Fork 0
generated from camel.apache.org/component
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update wiki Home page for spring-rabbitmq

gitea_admin 2026-03-11 14:42:33 +00:00
parent 4c357bbed1
commit ae604f3eca
1 changed files with 62 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
Home.md

@ -1,21 +1,69 @@
# Deploy the Project on CamelX Platform # Spring RabbitMQ
Deploy on CamelX Platform in three steps Send and receive messages from RabbitMQ using the Spring RabbitMQ client.
## Step 1: Create a release ## Metadata
From the project space, click on **"Create a release"**
The new version is automatically available in the list | Property | Value |
|----------|-------|
| Scheme | `spring-rabbitmq` |
| Support Level | Stable |
| Labels | messaging |
| Version | 4.10.2 |
## Step 2: Deploy ## Maven Dependency
Click on **"Deploy"**
- **Version:** Select the desired release ```xml
- **Environment:** Choose `Development`, `Staging`, or `Production` <dependency>
- **Configuration:** Select the configuration source <groupId>org.apache.camel</groupId>
- **Resources:** Set CPU and Memory <artifactId>camel-spring-rabbitmq</artifactId>
<version>4.10.2</version>
</dependency>
```
## Step 3: Expose ## Endpoint Properties
Enable **"Expose"**
Choose an **API Gateway** (Internal, Public, etc.) | Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `exchangeName` | string | ✓ | | The exchange name determines the exchange to which the produced messages will be sent to. In the case of consumers, the exchange name determines the exchange the queue will be bound to. Note: to use default exchange then do not use empty name, but use default instead. |
| `connectionFactory` | object | | | The connection factory to be use. A connection factory must be configured either on the component or endpoint. |
| `deadLetterExchange` | string | | | The name of the dead letter exchange |
| `deadLetterExchangeType` | string | | `direct` | The type of the dead letter exchange |
| `deadLetterQueue` | string | | | The name of the dead letter queue |
| `deadLetterRoutingKey` | string | | | The routing key for the dead letter exchange |
| `disableReplyTo` | boolean | | `false` | Specifies whether Camel ignores the ReplyTo header in messages. If true, Camel does not send a reply back to the destination specified in the ReplyTo header. You can use this option if you want Camel to consume from a route and you do not want Camel to automatically send back a reply message because another component in your code handles the reply message. You can also use this option if you want to use Camel as a proxy between different message brokers and you want to route message from one system to another. |
| `queues` | string | | | The queue(s) to use for consuming or producing messages. Multiple queue names can be separated by comma. If none has been configured then Camel will generate an unique id as the queue name. |
| `routingKey` | string | | | The value of a routing key to use. Default is empty which is not helpful when using the default (or any direct) exchange, but fine if the exchange is a headers exchange for instance. |
| `testConnectionOnStartup` | boolean | | `false` | Specifies whether to test the connection on startup. This ensures that when Camel starts that all the JMS consumers have a valid connection to the JMS broker. If a connection cannot be granted then Camel throws an exception on startup. This ensures that Camel is not started with failed connections. The JMS producers is tested as well. |
| `acknowledgeMode` | object | | | Flag controlling the behaviour of the container with respect to message acknowledgement. The most common usage is to let the container handle the acknowledgements (so the listener doesn't need to know about the channel or the message). Set to AcknowledgeMode.MANUAL if the listener will send the acknowledgements itself using Channel.basicAck(long, boolean). Manual acks are consistent with either a transactional or non-transactional channel, but if you are doing no other work on the channel at the same other than receiving a single message then the transaction is probably unnecessary. Set to AcknowledgeMode.NONE to tell the broker not to expect any acknowledgements, and it will assume all messages are acknowledged as soon as they are sent (this is autoack in native Rabbit broker terms). If AcknowledgeMode.NONE then the channel cannot be transactional (so the container will fail on start up if that flag is accidentally set). |
| `asyncConsumer` | boolean | | `false` | Whether the consumer processes the Exchange asynchronously. If enabled then the consumer may pickup the next message from the queue, while the previous message is being processed asynchronously (by the Asynchronous Routing Engine). This means that messages may be processed not 100% strictly in order. If disabled (as default) then the Exchange is fully processed before the consumer will pickup the next message from the queue. |
| `autoDeclare` | boolean | | `true` | Specifies whether the consumer should auto declare binding between exchange, queue and routing key when starting. |
| `autoStartup` | boolean | | `true` | Specifies whether the consumer container should auto-startup. |
| `exchangeType` | string | | `direct` | The type of the exchange |
| `exclusive` | boolean | | `false` | Set to true for an exclusive consumer |
| `maximumRetryAttempts` | integer | | `5` | How many times a Rabbitmq consumer will try the same message if Camel failed to process the message (The number of attempts includes the initial try) |
| `noLocal` | boolean | | `false` | Set to true for an no-local consumer |
| `rejectAndDontRequeue` | boolean | | `true` | Whether a Rabbitmq consumer should reject the message without requeuing. This enables failed messages to be sent to a Dead Letter Exchange/Queue, if the broker is so configured. |
| `retryDelay` | integer | | `1000` | Delay in millis a Rabbitmq consumer will wait before redelivering a message that Camel failed to process |
| `bridgeErrorHandler` | boolean | | `false` | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions (if possible) occurred while the Camel consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. Important: This is only possible if the 3rd party component allows Camel to be alerted if an exception was thrown. Some components handle this internally only, and therefore bridgeErrorHandler is not possible. In other situations we may improve the Camel component to hook into the 3rd party component and make this possible for future releases. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
| `concurrentConsumers` | integer | | | The number of consumers |
| `exceptionHandler` | object | | | To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |
| `exchangePattern` | object | | | Sets the exchange pattern when the consumer creates an exchange. |
| `maxConcurrentConsumers` | integer | | | The maximum number of consumers (available only with SMLC) |
| `messageListenerContainerType` | string | | `DMLC` | The type of the MessageListenerContainer |
| `prefetchCount` | integer | | | Tell the broker how many messages to send in a single request. Often this can be set quite high to improve throughput. |
| `retry` | object | | | Custom retry configuration to use. If this is configured then the other settings such as maximumRetryAttempts for retry are not in use. |
| `allowNullBody` | boolean | | `false` | Whether to allow sending messages with no body. If this option is false and the message body is null, then an MessageConversionException is thrown. |
| `autoDeclareProducer` | boolean | | `false` | Specifies whether the producer should auto declare binding between exchange, queue and routing key when starting. |
| `confirm` | string | | `auto` | Controls whether to wait for confirms. The connection factory must be configured for publisher confirms and this method. auto = Camel detects if the connection factory uses confirms or not. disabled = Confirms is disabled. enabled = Confirms is enabled. |
| `confirmTimeout` | duration | | `5000` | Specify the timeout in milliseconds to be used when waiting for a message sent to be confirmed by RabbitMQ when doing send only messaging (InOnly). The default value is 5 seconds. A negative value indicates an indefinite timeout. |
| `replyTimeout` | duration | | `30000` | Specify the timeout in milliseconds to be used when waiting for a reply message when doing request/reply (InOut) messaging. The default value is 30 seconds. A negative value indicates an indefinite timeout (Beware that this will cause a memory leak if a reply is not received). |
| `skipBindQueue` | boolean | | `false` | If true the queue will not be bound to the exchange after declaring it. |
| `skipDeclareExchange` | boolean | | `false` | This can be used if we need to declare the queue but not the exchange. |
| `skipDeclareQueue` | boolean | | `false` | If true the producer will not declare and bind a queue. This can be used for directing messages via an existing routing key. |
| `usePublisherConnection` | boolean | | `false` | Use a separate connection for publishers and consumers |
| `lazyStartProducer` | boolean | | `false` | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. |
| `args` | object | | | Specify arguments for configuring the different RabbitMQ concepts, a different prefix is required for each element: arg.consumer. arg.exchange. arg.queue. arg.binding. arg.dlq.exchange. arg.dlq.queue. arg.dlq.binding. For example to declare a queue with message ttl argument: args=arg.queue.x-message-ttl=60000 |
| `messageConverter` | object | | | To use a custom MessageConverter so you can be in control how to map to/from a org.springframework.amqp.core.Message. |
| `messagePropertiesConverter` | object | | | To use a custom MessagePropertiesConverter so you can be in control how to map to/from a org.springframework.amqp.core.MessageProperties. |
| `synchronous` | boolean | | `false` | Sets whether synchronous processing should be strictly used |