Apama 10.7.2 | Connecting Apama Applications to External Components | Correlator-Integrated Support for the Java Message Service (JMS) | Using the Java Message Service (JMS) | JMS configuration reference | XML configuration bean reference | Advanced configuration bean properties
 
Advanced configuration bean properties
The following properties are advanced tuning parameters, for use only when really necessary to improve performance or work around a JMS provider bug. Since these are advanced properties, it is possible that the default values may change in any future release or that new tuning parameters may be added that could alter the semantics of the existing ones, so be sure to carefully check the Release Notes when upgrading, if you use any of these properties.
JMSSenderSettings
*maxBatchSize - The maximum (and target) number of events to be batched together for sending inside a JMS local (non-XA) transaction (which improves performance on many JMS providers). The maxBatchSize indicates the target number of events that will normally be sent in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and the special value of 1 is used to indicate that a non-transacted JMS session should be used instead. Note that the same batching algorithm and parameters are used for both reliable and non-reliable senders. The default value in this release is 500.
*maxBatchIntervalMillis - The maximum time a sender will wait for more events on its channel (and for reliable senders, also included in a correlator persist cycle) before timing out and sending the events ready to be sent in the batch, even if the batch size is less than maxBatchSize. The default value in this release is 500 ms.
JMSReceiverSettings
*receiveTimeoutMillis - The timeout that will be passed to the JMS provider's MessageConsumer.receive(timeout) method call to indicate the maximum time it should block for when receiving the next message before returning control to the correlator. The default value in this release is 300 ms. Some providers may require this timeout to be increased to ensure that messages can be successfully received in high-latency network conditions, although well-behaved providers should always work correctly with the default value. Reducing this timeout may improve receive latency (due to reduced time waiting for the batch to complete) on some providers; although note that many JMS providers do not strictly obey the timeout specified here so the real time spent blocking while no messages are available may be significantly higher.
*maxBatchSize - The maximum (and target) number of JMS messages to be received before the batch is committed to the receive-side database (if receiver is using AT_LEAST_ONCE or EXACTLY_ONCE reliability mode) and then added to the input queues of public contexts and acknowledged to the JMS broker (whether reliable or not). The maxBatchSize indicates the target number of messages that will normally be received in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and for BEST_EFFORT (non-reliable) receivers the special value of 1 is used to indicate that an AUTO_ACKNOWLEDGE session will be used instead of the default CLIENT_ACKNOWLEDGE session (though for reliable receivers CLIENT_ACKNOWLEDGE is always used even if maxBatchSize is 1). The default value in this release is 1000.
The batch size becomes particularly important when using the APP_CONTROLLED reliability mode. In this case, you might need to tweak the batch size to improve throughput based on how long the application takes between suspending and acknowledging each batch of messages.
*maxBatchIntervalMillis - the maximum time a receiver will attempt to wait for more messages to be received (and mapped) before timing out and processing the messages already received as a single batch, even if the size of that batch is less than maxBatchSize. The default value in this release is 500 ms. Note that in practice, when no messages are available, many JMS providers seem to block for longer than the specified receiveTimeoutMillis before returning, which may lead to the true maximum batch interval being significantly longer than the value specified here.