Deploying and Managing Apama Applications > Deploying and Configuring Correlators > The correlator tabs > Configuration tab
Configuration tab
This tab contains a number of parameters that configure how a correlator operates. As all of these are startup parameters, you should adjust them before you start the component. If the component is already running they will only take effect the next time it is started.
The following parameters are available for a correlator:
*Listen on port – Port on which the correlator should listen for monitoring and management requests (default is 15903). The correlator will fail to start if this port is in use by any other component, or for that matter by any other software that is running on the relevant host.
Note: The highest permitted port number for correlators and other components managed through EMM is 65534.
*Log level – Sets the log level the event correlator should log at. This must be one of OFF, CRIT, FATAL, ERROR, WARN, INFO, DEBUG, or TRACE (in increasing order of verbosity). The default level is INFO.
*Log file name - Sets the filename that the event correlator should write log messages to (on the file system of the host the correlator is running on). It is recommended that an absolute path be provided. See Specifying paths and filenames in the Details Pane for more information about setting filename options correctly.
*Diagnostic replay log file name - Enables and sets the filename for a diagnostic replay log. A diagnostic replay log collects all messages sent to the correlator and writes then to a file on the file system of the host the correlator is running on. The replay log provides useful input to help Apama technical support diagnose problems with a correlator or an application running on the correlator.
It is recommended that an absolute path be provided. See Specifying paths and filenames in the Details Pane for more information about setting filename options correctly. For more information on diagnostic replay log files, see Injecting code into a correlator.
*Diagnostic replay log type - Specifies whether the correlator will use a full replay log or an input-only replay log. The default is to use a full replay log. The differences are:
*A full replay log lets you replay the exact same behavior, ordering of emit operations, and so on, as the run that generated the replay log.
*An input-only replay log contains only the external inputs to the correlator. There is no information about multi-context ordering. Consequently, if there is more than one context, there is no guarantee that you can replay execution in the same order as the original execution.
*For more information on the replay log types, see Comparison of full replay logs and input-only replay logs.
*Java application support (JMON) – Enables support for Apama Java applications. If this is not set, any attempt to inject a Java application either using engine_inject –j or by adding a .jar file Inject initialization action will result in an error. The correlator’s performance is improved when Java application support is disabled.
*Extra command line arguments – This option allows additional unspecified command line arguments to be passed to the correlator. For example these might be special options to pass to the embedded JVM used for Apama Java applications, or special settings provided to you by Apama Customer Support to address specific issues.
*Performance tuning – Specifies whether the correlator should be configured to favor Low Latency or High Throughput.
*Low latency – The transport waits until an event is on the correlator’s queue. The transport then sends, in one batch, as many events as are available on the queue. Because of thread scheduling effects, this can be more than the event that woke up the transport. This is the default behavior for multiprocessor machines.
*High throughput – The transport waits 10 milliseconds before it tries to send any events. Typically, during that time, the correlator emits enough events to its output queue to form an efficient batch. This is the default behavior for uniprocessor machines.
For more information about this option, see About the low latency and high throughput options.
*Slow receivers – Tells the event correlator to disconnect any receiver whose output queue becomes full; that is, a receiver that cannot consume events fast enough. Without this option, the event correlator would eventually stop processing events altogether, (and block) until some output events are consumed by the receiver, freeing space on its output queue.
Click on the Commit Changes button when you are finished customizing the new correlator. This applies these outstanding changes for use when the correlator is actually started.
The Default button resets all outstanding parameter values to their defaults, while the Revert button reverts the outstanding parameter values to their current committed values.
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.