|
This page last changed on Jun 02, 2006 by stephen fenech.
All mule configuration is accessible form a single object org.mule.config.MuleConfiguration that can be accessed using -
MuleConfiguration config = MuleManager.getConfiguration();
Configuration Variables
The configuration object mule uses is org.mule.config.MuleConfiguration defines the following properties.
| Property Name |
Description |
| model |
A property file can specify more than one mule-model. In the situation when more than one is defined, this property tells Mule which model to load. If this is not specifed the first model is used. This property currently is not used |
| serverUrl |
This is the url used by the server itself to recieve incomming requests. This enables clients such as the Mule Client to marshal remote requests to a MuleManager instance. The default value is tcp://localhost:60504. If you set the serverUrl to an empty string, Mule server components will not be set up, this can be useful when testing. |
| configResources |
Is a String array of the config resources names used to configure the server instance. This property is automatically set by the configuration builder used to construct the Mule instance and cannot be set directly. |
| workingDirectory |
The directory where mule can write any temporary files or persist messages. the default value for this is ./.mule |
| synchronous |
Specifies whether mule should process messages sysnchonously, i.e. that a mule-model can only processone message at a time, or asynchonously. The default value is 'false' |
| synchronousReceive |
Determines whether when running synchronously, return events are received before returning the call. i.e. in jms whether to wait for a replyTo message. Note that it's usually a good idea to turn this off unless a result from a remote invocation is expected as the call will block until it times out. If you want to make specific synchronous receive calls per event you can set the MuleProperties.SYNCHRONOUS_RECEIVE property on the event i.e. event.setProperty(MuleProperties.SYNCHRONOUS_RECEIVE, "true");. The default value is 'false' |
| synchronousEventTimeout |
When running sychonously and using synchronousReceive, return events can be received over transports that support ack or replyTo his property determines how long to wait in milliseconds for a receive before timeing out. The default value is '3000' |
| recoverableMode |
Determines whether Mule's internal queues are persisted. If the server dies unexpectedly Mule can resume processing when the server starts. Default value for this is 'false' |
| poolingProfile |
A pooling profile is used to configure the pooling behaviour of UMO components. Each Mule component descriptor can set it's own pooling profile otherwise the one specified here will be used |
| queueProfile |
This is the default queue profile used to create internal queues for managaed components. Develpers can specify a queue profile for each Mule Maanaged component if that component need a different configuration to other components in the system. By default non-persistent queues are used with a maxOutstandingMessage size of 1000 |
| defaultThreadingProfile |
This defines the default threading profile if no other is specified. Threading profiles can be specified for component pooling, message dispatcher and message receivers |
| componentPoolThreadingProfile |
Allows the developer to define a specific Threading profile for all components. You can also specify threading profiles at the component level |
| messageReceiverThreadingProfile |
Defines the Threading profile used by Connecotr message receivers when receiving messages. It is also possible to set a threading profile for a message receiver on the connector |
| messageDispatcherThreadingProfile |
Defines the Threading profile used by Connecotr message dispatchers when the connector dispatches an event. It is also possible to set a threading profile for a message dispatcher on the connector |
Pooling Profiles
A pooling profile is used to configure the pooling behaviour of UMO components. each descriptor can set it's own pooling profile or a default one can be set on the mule-configuration. The org.mule.config.PoolingProfile contains all the necessary values to create a pool of UMOComponent proxies.
| Property Name |
Description |
Default |
| maxActive |
Controls the maximum number of Mule UMOs that can be borrowed from a Session at one time. When non-positive, there is no limit to the number of components that may be active at one time. When maxActive is exceeded, the pool is said to be exhausted. |
5 |
| maxIdle |
Controls the maximum number of Mule UMOs that can sit idle in the pool at any time. When non-positive, there is no limit to the number of Mule UMOs that may be idle at one time. |
5 |
| initialisationPolicy |
Determines how components in a pool should be initialised. the possible values are -
* POOL_INIT_NO_COMPONENT (0) : Will not load any components in the pool on startup
* POOL_INIT_ONE_COMPONENT (1) : Will load only the first component in the pool on startup
* POOL_INIT_ALL_COMPONENTS (2) : Will load all components in the pool on startup |
POOL_INIT_ONE _COMPONENT |
| exhaustedAction |
Specifies the behaviour of the Mule UMO pool when the pool is exhausted:
* WHEN_EXHAUSTED_FAIL (0) : will throw a NoSuchElementException
* WHEN_EXHAUSTED_BLOCK (1) : will block (invoke Object.wait(long) until a new or idle object is available.
* WHEN_EXHAUSTED_GROW (2) : will create a new Mule and return it(essentially making maxActive meaningless.)
If a positive maxWait value is supplied, it will block for at most that many milliseconds, after which a NoSuchElementException will be thrown. If maxThraedWait is non-positive, it will block indefinitely. |
WHEN_EXHAUSTED _GROW |
| maxWait |
Specifies the number of milliseconds to wait for a pooled component to become available when the pool is exhausted and the exhaustedAction is set to WHEN_EXHAUSTED_BLOCK. |
4000 |
| factory |
A fully qualified classname of the pool factory to use with this pool profile. Implementations must implement org.mule.util.ObjectFactory |
|
Threading Profiles
Threading Profiles are used to control how thread pools behave in Mule. Thread pools in Mule use the JDK 1.4-compatible util.concurrent backport library so all the variables defined on org.mule.config.ThreadingProfile are synonymous with ThreadPoolExecutor.
| Property Name |
Description |
Default |
| id |
The threading profile system id is used to identify which system component should use the profile. This attribute is only used when declaring profiles on the mule-evironment-properties element and on connector components where 'messageReciever', 'messageDispatcher', 'component' or 'default' can be used. For all other cases it can be set to 'default' |
default |
| maxThreadsActive |
Controls the maximum number of threads that can be executed at any one time in a thread pool. |
10 |
| maxThreadsIdle |
Controls the maximum number threads that can be inactive or idle in a thread pool before they are destroyed. |
10 |
| threadTTL |
Detemines how long an inactive thread is kept in the pool before being discarded. |
60000 |
| poolExhaustedAction |
If the maximum pool size or queue size is bounded, then it is possible for incoming execute requests to block. There are five supported policies for handling this situation:
* WHEN_EXHAUSTED_RUN : (4) - The thread making the execute request runs the task itself. This policy helps guard against lockup.
* WHEN_EXHAUSTED_WAIT : (0) - Wait until a thread becomes available. This policy should, in general, not be used if the minimum number of of threads is zero, in which case a thread may never become available.
* WHEN_EXHAUSTED_ABORT : (3) - Throw a RuntimeException
* WHEN_EXHAUSTED_DISCARD : (1) - Throw away the current request and return.
* WHEN_EXHAUSTED_DISCARD_OLDEST : (2) - Throw away the oldest request and return. |
WHEN_EXHAUSTED_RUN |
| threadWaitTimeout |
Controls the time to wait for the WHEN_EXHAUSTED_WAIT policy, in seconds. Use -1 (or any other negative value) to wait forever. |
30 |
| maxBufferSize |
Determines how many requests if any are queue when the pool is at maximum usage capacity. The buffer is used as an overflow. |
0 |
Queue Profiles
A Queue Profile is used to describe the the properties of an internal Mule queue. Internal queues are used to queue events for each component managed by Mule.
| Property Name |
Description |
Default |
| maxOutstandingMessage |
Defines the maximum number of message that can be queued. |
1000 |
| persistenceStrategy |
A persistence strategy defines the mechanism used to store Mule events to a persistent store. Primarily, this is used for for persisting queued events to disk so that the servers internal state is mirrored on disk in case the server fails and needs to be restarted. If no strategy is set the any queues created from this profile are not persistent |
null |
|
