Open topic with navigation

TIBCO BusinessEvents® Enterprise Edition 6.3.1

# CDD Agent Classes Tab Properties Reference

Properties are available for inference agents, cache agents, and query agents.

## Inference Agent and Query Agent Properties

`com.tibco.cep.runtime.channel.payload.validation`
  XML event payloads are validated when this property is set to true. There may be some loss of performance due to the extra processing.

  Default is `false`.

`com.tibco.cep.runtime.threadpool.shutdown.timeout.seconds`
  Specifies the time (in seconds) to wait for the worker thread to complete before shutdown.

## Inference Agent Properties

`Agent.AgentClassName.recoveryPageSize`
  Specifies the number of entries per page to be used while recovering objects from the cache.

  For example, if you set the value to 10,000, then the engine loads handles in blocks of 10,000, instead of trying to load them in a single batch. Smaller batch sizes result in slower recovery. Experiment with batch size to establish the best batch size to use for your environment.

  A value of 0 means that the objects are recovered in one iteration.

  Default is `0`.

`Agent.AgentClassName.cacheTxn.updateCache`
  Used only if a cache-aside database write strategy is used.

  If set to false: When a rule action changes the value of an entity’s properties or adds a new entity, then the entity instance is evicted from the cache instead of updating it. Updates are saved in the backing store. Use this setting and `Agent.AgentClassName.threadcount` as needed to improve performance and cache memory management.

  This property interacts with the Cluster > Domain Objects setting, Evict From Cache on Update (and its override settings if any):

  - When this CDD property is set to true, the domain objects Evict From Cache on Update setting is ignored, in the agent for which the property is set.
  - When this CDD property is set to false, the domain objects Evict From Cache on Update setting overrides this CDD property.

    See Domain Objects Default Settings Reference for details on the Evict From Cache on Update setting.

    Possible values are `true` and `false.`

    Default is `true.`

  Note: `AgentName` in the property refers to the name of the agent that actually evicts entities, for example, `inference-class`.
`Agent.AgentClassName.threadcount`
  For use with cache aside and only when parallel operations feature is used (see `Agent.``agentClassName``.enableParallelOps`).

  Defines the number of `$CacheWriter` threads performing cache writing jobs.

  See Threading Models and Tuning in TIBCO BusinessEvents Architect’s Guide for usage guidelines.

  The default value is `2`.

`Agent.AgentClassName.checkDuplicates`

  This property is available only when the legacy id lookup strategy is enabled for a project.

  This property affects how TIBCO BusinessEvents checks the uniqueness of entity external IDs (@extId).

  If set to false, checks for uniqueness of external IDs within the agent

  If set to true, checks for the uniqueness of external IDs across the cluster. Performing this check affects performance so use it with care.

  Default is false.

Inference Agent Database Writer Thread Tuning Properties

Note: For use with cache aside and only when the parallel operations feature is used.

For a guide to usage, refer to the "Database Write Tuning Options for Cache Aside" section in the TIBCO BusinessEvents Architect’s Guide.

`Agent.agentClassName.enableParallelOps`
  If true, parallel operations are used
  Post-RTC phase operations are done in parallel:
  - Writes to the cache
  - Writes to the database (only relevant cache aside strategy is used)
  - Runs the actions list, for example, sends messages (events) and acknowledges events as needed.

    Use of parallel operations generally requires the use of locking to ensure data integrity.

  If false, sequential operations are used
  All post-RTC phase operations are done by the worker thread in the order shown above. When concurrentRTC is enabled, multiple worker threads perform post RTC operations in parallel (locking required).

  This property is set to false for specific needs such as when the Caller’s Thread threading option is used.

  Another reason to set the value to false is to ensure that the system waits to send a reply event confirming that some work has been done, until the result of the work can be seen in the cache.

  Defaults to true only if cache-aside write strategy and concurrent RTC are both used. Otherwise defaults to false.

`Agent.AgentClassName.dbthreadcount`
  Defines the number of database write threads available to process the RTC transactions from the queue, that is, the number of threads performing database writing jobs (`$DBWriter` thread pool). Writes include applying entity inserts, updates, and delete to the database.

  Although the limit is seldom reached, you can guarantee that a connection is always available for a `dbwriter` thread as follows. Set this field to the same value as CDD Cluster tab > Persistence Store > Connection > Max Size field.

  Default is `2`.

`Agent.AgentClassName.dbOpsQueueSize`
  The size of the queue (a Java blocking queue) for database writing jobs.

  Zero (0) or a negative value means that the queue size is unlimited.

  Default is `8`.

  Note: When the queue is full, all engine operations are blocked.
`Agent.AgentClassName.dbOpsBatchSize`
  Used in the post-RTC phase. Sets the maximum number of RTC transactions that a database writer thread takes from the database operations queue and processes in one batch.

  Database write threads process the RTC transactions from the queue. The number of threads is defined by `dbthreadcount`.

  A database write thread takes up to the `dbOpsBatchSize` number of RTC transactions, processes them and commits them to the database. (When database write threads are idle, they take available jobs from the database operations queue, even if there are less jobs than `dbOpsBatchSize`.)

  Default is `10`.

## Query Agent Properties

`be.agent.query.localcache.prefetchaggressive`
  If set to true, then the objects required for a query are prefetched while the query is running.

  The prefetch feature improves performance, but CPU and memory usage increases as a result of the aggressive prefetching. You may have to try different values until you find the optimal settings for your environment.

  Ensure that the cache size is large enough to accommodate objects that are prefetched.

  Default is `false`.

`be.engine.queryAgent.channel.disable`
  By default, query agents connect to channels. In some cases, however, query agents do not need to connect to channels. To prevent query agents from connecting to channels, set this property to `true.`

  The default value is `false.`

## Cache Agent Properties

`be.engine.cacheServer.channel.disable`
  By default cache agents connect to channels. In most cases, however, cache agents do not need to connect to channels. To prevent cache agents from connecting to channels, set this property to `true.`

  The default value is `false.`

`be.engine.cluster.scheduler`
  A single agent of the cluster acts as a scheduler. By default all agents of a cluster can act as a scheduler. To avoid that a Cache Agent acts as a scheduler, add the property and set it to false for the Cache Agent classes.

  The default value is true

`be.engine.cluster.datagrid.scheduler.persistence.policy`
  Specifies the type of communication to be used to maintain persistence in the scheduler cache: asynchronous (`ASYNC`) or synchronous (`SYNC`). This property overrides the Persistence Policy field (set at the cluster level) for the scheduler. This property has no default value and if not set, it takes the value of the Persistence Policy field.
  - `ASYNC` - This policy is recommended to avoid frequent IO operations, which can slow cache agents.
  - `SYNC` - This policy is recommended for flushing out the completed entries from the scheduler caches.
`com.tibco.cep.runtime.scheduler.registerCacheEvents`

  The scheduler processes events in the following ways:

  1. Periodically looking into the cache and scheduling and expiring those events.

  2. Listening to puts on the cache and as soon as the put happens, check if it can be scheduled.

  When there is a continuous load, Apache Ignite cache events (puts) are scheduled even though they are not required to be scheduled immediately. In most cases, you do not schedule events to be triggered immediately. This cause Ignite buffer limits to exceed for a slower network. Because of this, nodes get disconnected and reconnected continuously.

  To disable such inline processing of scheduler events, set the property `com.tibco.cep.runtime.scheduler.registerCacheEvents` to `false.`

  The default value is `true.`

Did you find this helpful?

YesNo
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO BusinessEvents® Enterprise Edition

Copyright © 2004-2024. Cloud Software Group, Inc. All Rights Reserved.