If createMultipleTransactedReceivers
is set to true
, defines the number of concurrent receivers that is launched.
For example, consider a VM transport configured with numberOfConcurrentTransactedReceivers
set to 3
. This endpoint launches three processes that concurrently consume messages from the queue and send them to the flow.
Configuring a Transport
You can configure a transport in the following ways:
-
Define a connector configuration using the
<connector>
element in the Mule XML configuration file. -
Set transport properties on endpoints to customize the transport behavior for a single endpoint instance.
-
Use an endpoint URI that defines the scheme and connection information for the transport, such as
tcp://localhost:12345
. See Mule Endpoint URIs for more information. The URI consists of the protocol followed by transport-specific information, and then zero or more parameters to set as properties on the connector.
This page describes the common properties for all transports. The actual configuration parameters for each transport type are described separately for each transport. To see the details of a specific transport, see Transports Reference.
Common Connector Properties
All connectors require that you set the name
attribute to a unique name for that connector. Additionally, they all include the following common properties.
Property | Description | Default | Required |
---|---|---|---|
|
The exception strategy to use when errors occur in the connector. |
No |
|
|
The threading properties and WorkManager to use when receiving events from the connector. |
The default receiver threading profile set on the Mule Configuration |
Yes |
|
The threading properties and WorkManager to use when dispatching events from the connector. |
The default dispatcher threading profile set on the Mule Configuration. |
Yes |
|
Desupported as of Mule 2.0. Use retry policies instead. |
No |
|
|
A map of service configuration values that can be used to override the default configuration for this transport. |
No |
|
|
Only used for inbound endpoints with a configured transaction. Creates multiple concurrent receivers, that extend |
|
No |
|
No |
||
|
Whether to enable dynamic notification. |
|
No |
|
Causes Mule to validate connections before use. Note that this is only a configuration hint; transport implementations may or may not make an extra effort to validate the connection. |
|
No |
Setting Spring Properties on Connectors
You can also set a Spring property on a connector. This is especially useful if you are using a custom connector.
For example, you can set a Spring property to define the maximum time a socket will be left open on a TCP or HTTP connector, regardless of what happens with the client or data transfer from the client. To do this, include a Spring property to define a value for the keepAliveTimeout
property, as shown:
xmlns:spring="http://www.springframework.org/schema/beans"
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
...
<http:connector name="httpConnector">
<spring:property name="keepAliveTimeout" value="5000" />
</http:connector>
Note that this keepAliveTimeout
example is only relevant for the TCP and HTTP connectors and may not work with other connectors.
See Using Mule with Spring for information on setting Spring properties.
Retry Policies
Retry policies are used to configure how a connector behaves when its connection fails. For complete information, see Configuring Reconnection Strategies.
Creating Your Own Transport
For information on creating a custom transport for Mule, see Creating Transports.
Receiver Threading Profile
The threading profile to use when a connector receives messages.
Attributes of <receiver-threading-profile…>
Name | Type | Required | Default | Description |
---|---|---|---|---|
|
integer |
no |
The maximum number of threads to use. |
|
|
integer |
no |
The maximum number of idle or inactive threads that can be in the pool before they are destroyed. |
|
|
integer |
no |
Determines how long an inactive thread is kept in the pool before being discarded. |
|
|
|
no |
When the maximum pool size or queue size is bounded, this value determines how to handle incoming tasks. Possible values are:
|
|
|
integer |
no |
How long to wait in milliseconds when the pool exhausted action is |
|
|
integer |
no |
Determines how many requests are queued when the pool is at maximum usage capacity and the pool exhausted action is |
|
|
boolean |
no |
|
Whether threading should be used (default is |
Dispatcher Threading Profile
The threading profile to use when a connector dispatches messages.
Attributes of <dispatcher-threading-profile…>
Name | Type | Required | Default | Description |
---|---|---|---|---|
|
integer |
no |
The maximum number of threads to use. |
|
|
integer |
no |
The maximum number of idle or inactive threads that can be in the pool before they are destroyed. |
|
|
integer |
no |
Determines how long an inactive thread is kept in the pool before being discarded. |
|
|
|
no |
When the maximum pool size or queue size is bounded, this value determines how to handle incoming tasks. Possible values are:
|
|
|
integer |
no |
How long to wait in milliseconds when the pool exhausted action is |
|
|
integer |
no |
Determines how many requests are queued when the pool is at maximum usage capacity and the pool exhausted action is |
|
|
boolean |
no |
|
Whether threading should be used (default is |
Service Overrides
Service overrides allow the connector to be further configured/customized by allowing parts of the transport implementation to be overridden, for example, the message receiver or dispatcher implementation, or the message adaptor that is used.
Attributes of <service-overrides…>
Name | Type | Required | Default | Description |
---|---|---|---|---|
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |
||
|
string |
no |