Configuring CXF workqueues
CXF workqueues are used for queuing incoming work requests using a thread pool.
The etc/org.apache.cxf.workqueues.cfg configuration file is used for workqueue configuration (without this file, the configuration would need to be done for each individual bundle using CXF services). This process can significantly optimize the performance of HTTP / CXF Service request handling in the Talend Runtime Container.
This mechanism allows you to configure global workqueues for use by all bundles that are created, and normally services would share a thread pool. However an individual service can override this via local configuration if they have specific requirements.
Usage of queues
Workqueue settings may be used in different scenarios:
-
For SOAP-based web service providers, the ws-addressing workqueue (Configuration files Configuration files) can be used, and the default workqueue for One-Way (no response) SOAP calls. (Workqueues are not applicable for REST endpoints.)
-
For JMS transport, workqueues are active to handle continuations; for regular JMS, there are similar settings, like the number of consumers or the thread pool for execution, which are implemented outside of workqueues.
-
SOAP clients can use the "http-conduit" workqueue for asynchronous calls.
Configuration parameters
A configuration file contains the following parameters:
| Name | Description | Default value |
|---|---|---|
| org.apache.cxf.workqueue.names | One or more names of workqueues, separated by commas | 'default' |
| org.apache.cxf.workqueue.default. highWaterMark | Maximum number of threads to work on the queue | 10 |
| org.apache.cxf.workqueue.default. lowWaterMark | Minimum number of threads to work on the queue | 5 |
| org.apache.cxf.workqueue.default. initialSize | Initial number of threads to work on the queue | 7 |
| org.apache.cxf.workqueue.default. dequeueTimeout | This is the keep alive time for the threadpool executor. This allows excess threads to be terminated when idle for longer than this time, and they can be created again later if needed. | 100 (optional) |
| org.apache.cxf.workqueue.default. queueSize | Maximum number of entries in the queue | 100 (optional) |
Configuration files
In the Talend Runtime Container, the default configuration file is in etc/org.apache.cxf.workqueues.cfg.
Note this file is normally not used or edited directly; it gives workqueue default values that each CXF-using bundle can choose to employ when it creates its work queues.
To configure a workqueue, there is a specific corresponding file: org.apache.cxf.workqueues-n.cfg, where typically "n" is the same as the workqueue name; for example, org.apache.cxf.workqueues-http-conduit.cfg would configure the http-conduit workqueue. At the moment, this functionality is for pre-defined work queues; it is not possible to use it for user-defined workqueues.
Here is the list of pre-defined workqueue names:
|
Name |
Description |
|---|---|
| default | this means using the default values. |
| http-conduit | On the client side when using the asynchronous methods, the HTTP conduit must wait for and process the response on a background thread. This can control the queue that is used specifically for that purpose, to limit or expand the number of outstanding asynchronous requests. |
| jms-continuation | This is used by the JMS transport to handle continuations. |
| local-transport | The local transport being based on PipedInput/OutputStreams requires the use of separate threads; this workqueue can be used to configure the queue used exclusively for the local-transport. |
| ws-addressing | For decoupled cases, the ws-addressing layer may need to process the request on a background thread. This can control the workqueue it uses. |