{table-plus:columnAttributes=,,style="text-align:center;",style="text-align:center;"}
|| Parameter || Description || Default || Scope* ||
| acceptor-pool-size | The size of the thread pool used to accept Message Exchanges from the NMR. Once a message is accepted, its processing is delegated to the processor pool thread. | 1\\ | Runtime\\ |
| acceptor-retry-number | Number of tries to submit a message exchange to a processor for processing before to declare that it cannot be processed. | 40\\ | Installation\\ |
| acceptor-retry-wait | Base duration, in milliseconds, to wait between two processing submission tries. At each try, the new duration is the previous one plus this base duration. | 250\\ | Installation\\ |
| acceptor-stop-max-wait | The max duration (in milliseconds) before, on component stop, each acceptor is stopped by force. | 500\\ | Runtime\\ |
| processor-pool-size | The size of the thread pool used to process Message Exchanges. Once a message is accepted, its processing is delegated to one of the thread of this pool. | 10 | Runtime |
| processor-max-pool-size | The maximum size of the thread pool used to process Message Exchanges. The difference between this size and the processor-pool-size represents the dynamic threads that can be created and destroyed during overhead processing time. \\ | 50\\ | Runtime\\ |
| processor-keep-alive-time | When the number of processors is greater than the core, this is the maximum time that excess idle processors will wait for new tasks before terminating, in seconds. \\ | 300\\ | Runtime\\ |
| processor-stop-max-wait | The max duration (in milliseconds) of message exchange processing on stop phase (for all processors).\\ | 15000\\ | Runtime\\ |
| time-beetween-async-cleaner-runs | The time (in milliseconds) between two runs of the asynchronous message exchange cleaner.\\ | 2000\\ | Installation\\ |
| properties-file | Name of the file containing properties used as reference by other parameters. Parameters reference the property name using a placeholder in the following pattern $\{myPropertyName}. At runtime, the expression is replaced by the value of the property.\\
\\
The properties file can be reloaded using the JMX API of the component. The runtime configuration MBean provides an operation to reload these place holders. Check the service unit parameters that support this reloading. \\

| activate-flow-tracing | Enable ('{{true}}') or disable ('{{false}}') the flow tracing. This value can be overridden at service consumer or service provider level, or at exchange level. | {{true}} | Runtime |
| propagate-flow-tracing-activation | Control whether the flow tracing activation state must be propagated to next flow steps or not. If '{{true}}', the flow tracing activation state is propagated. This value can be overridden at service consumer level. | {{true}} | Runtime |
| component-interceptors | Component interceptor configuration. See CDK Component interceptor configuration. | \- | See Maven Petals plugin to known how to inject component interceptor configuration in component configuration |
{table-plus}
\\* Definition of CDK parameter scopes:
* *Installation*: The parameter can be set during the installation of the component, by using the installation MBean (see JBI specifications for details about the installation sequence). If the parameter is optional and has not been defined during the development of the component, it is not available at installation time.
* *Runtime*: The paramater can be set during the installation of the component and during runtime. The runtime configuration can be changed using the CDK custom MBean named RuntimeConfiguration. If the parameter is optional and has not been defined during the development of the component, it is not available at installation and runtime times.