If messages should be auto acknowledged
If it is true, the exchange will be deleted when it is no longer in use
If we are declaring a durable exchange (the exchange will survive a server restart)
The queue to receive messages from
The routing key to use when binding a consumer queue to the exchange. For producer routing keys, you set the header (see header section)
The consumer uses a Thread Pool Executor with a fixed number of threads. This setting allows you to set that number of threads.
username in case of authenticated access
password for authenticated access
the vhost for the channel
Camel 2.12.2: The exchange type such as direct or topic.
Camel 2.12.3: If the bridgeEndpoint is true, the producer will ignore the message header of "rabbitmq.EXCHANGE_NAME" and "rabbitmq.ROUTING_KEY"
Camel 2.12.3: If this option is set, camel-rabbitmq will try to create connection based on the setting of option addresses. The addresses value is a string which looks like "server1:12345, server2:12345"
Camel 2.14: Connection timeout
Camel 2.14: Connection requested channel max (max number of channels offered)
Camel 2.14: Connection requested frame max (max size of frame offered)
Camel 2.14: Connection requested heartbeat (heart-beat in seconds offered)
Camel 2.14: Enables SSL on connection, accepted value are `true`, `TLS` and 'SSLv3`
Camel 2.14: Configure SSL trust manager, SSL should be enabled for this option to be effective
Camel 2.14: Connection client properties (client info used in negotiating with the server)
Camel 2.14: Custom RabbitMQ connection factory. When this option is set, all connection options (connectionTimeout, requestedChannelMax...) set on URI are not used
Camel 2.14: Enables connection automatic recovery (uses connection implementation that performs automatic recovery when connection shutdown is not initiated by the application)
Camel 2.14: Network recoverty interval in milliseconds (interval used when recovering from network failure)
Camel 2.14: Enables connection topology recovery (should topology recovery be performed?)
Camel 2.14: Enables the quality of service on the RabbitMQConsumer side, you need to specify the option of prefetchSize, prefetchCount, prefetchGlobal at the same time
Camel 2.14: The maximum amount of content (measured in octets) that the server will deliver, 0 if unlimited.
Camel 2.14: The maximum number of messages that the server will deliver, 0 if unlimited.
Camel 2.14: If the settings should be applied to the entire channel rather than each consumer
|true||Camel 2.14: If the option is true, camel declare the exchange and queue name and bind them together. If the option is false, camel won't declare the exchange and queue name on the server.|
Camel 2.14: Number of concurrent consumers when consuming from broker. (eg similar as to the same option for the JMS component).
Camel 2.14: The routing key for the dead letter exchange
Camel 2.14: The name of the dead letter exchange
Camel 2.14: The type of the dead letter exchange
Camel 2.14.1: (Producer only) Maximum number of channels used to send messages
Camel 2.14.1: (Producer only) Maximum time (in milliseconds) waiting for a channel
|null||Camel 2.15.1: the custom ArgsConfigurer instance which could be used to configure the Args map when declaring the queue.|
Camel 2.15.1: the custom ArgsConfigurer instance which could be used to configure the Args map when declaring the exchange.
Camel 2.16: Producer Only: The timeout for waiting for a reply when using the InOut Exchange Pattern (in milliseconds). The default is 20 seconds. See also the requestTimeoutCheckerInterval option.
Camel 2.16: Configures how often Camel should check for timed out Exchanges when doing request/reply over RabbitMQ. By default Camel checks once per second. But if you must react faster when a timeout occurs, then you can lower this interval, to check more frequently. The timeout is determined by the option requestTimeout.
Camel 2.16: If enabled and you are using Request Reply messaging (InOut) and an Exchange failed on the consumer side, then the caused
Exception will be sent back in the response as a byte. If the client is Camel, the returned
Exception is rethrown. This allows you to use Camel RabbitMQ as a bridge in your routing - for example, using persistent queues to enable robust routing. The caught exception is required to be serializable. The original
Exception on the consumer side can be wrapped in an outer exception such as
org.apache.camel.RuntimeCamelException when returned to the producer.
|Camel 2.16.1: If true the producer will not declare and bind a queue. This can be used for directing messages via an existing routing key.|
|skipExchangeDeclare||false||Camel 2.17.1: This can be used if we need to declare the queue but not the exchange|
|false||Camel 2.17: When true, the message will be published with publisher acknowledgements turned on|
|0||Camel 2.17: The amount of time in milliseconds to wait for a basic.ack response from RabbitMQ server|