JVM Properties Reference
Properties can be passed to the Java Virtual Machine (JVM) to affect the behavior of ActiveMatrix BPM.
JVM properties are set on the BPM node using ActiveMatrix Administrator. For more information, see Configuring JVM Properties on the BPMNode.
The following table lists all of the JVM properties that can be set as a JVM argument using ActiveMatrix Administrator. Some of these properties are described in more detail in other topics. For those, links or citations are provided in the description.
| JVM Property | Description |
|---|---|
| com.tibco.bx.allow.null.msgpart | Controls whether an exception is thrown if a required parameter is not initialized (that is, it is null) on a web service call. |
| com.tibco.bx.arrayDelimiter | Specifies the delimiter between array elements provided in a setAvailableProcessInstanceVariables request. The default value for the delimiter is ", " (comma followed by a space) if this property is not set.
For more information, see "SOAP API - setAvailableProcessInstanceVariables" in the TIBCO ActiveMatrix BPM Developer's Guide. |
| com.tibco.bx.autoDelete | Specifies whether process instances are automatically deleted from the database upon completion.
Also see com.tibco.bx.bpel.maintenance.purgeProcess.interval. Default = no |
| com.tibco.bx.autoDeleteFailedProcesses | Specifies whether failed process instances are automatically deleted from the database.
For more information, see "Configuration of Error Handling Behavior for Process Instances" in the TIBCO ActiveMatrix BPM Administration guide. Default = no |
| com.tibco.bx.bg.globalSignalProcessor.interval | Specifies how frequently expired global signals are cleaned up. Specified as either of the following:
Default = P30 Also see Expired Signals Job. |
| com.tibco.bx.bg.globalSignalProcessor.numMsgs | The batch size for expired global-signal cleanup jobs, that is, the number of expired signals that are to be processed at one time.
Default = 500 Also see Expired Signals Job. |
| com.tibco.pvm.deleteWorkItem
com.tibco.bx.bg.requestQueueCleanup.batchCount com.tibco.bx.bg.requestQueueCleanup.batchSize com.tibco.bx.bg.requestQueueCleanup.interval |
By default, rows in the PVM_REQUEST_QUEUE database table are removed when Process Manager has completed processing them.
These properties can be used to override this default behavior. For details, see Configuring Cleanup of the PVM_WORK_ITEM or PVM_REQUEST_QUEUE Database Tables |
| com.tibco.pvm.deleteRequestQueueItem
com.tibco.bx.bg.workItemCleanup.batchCount com.tibco.bx.bg.workItemCleanup.batchSize com.tibco.bx.bg.workItemCleanup.interval |
By default, rows in the PVM_WORK_ITEM database table are removed when Process Manager has completed processing them.
These properties can be used to override this default behavior. For details, see Configuring Cleanup of the PVM_WORK_ITEM or PVM_REQUEST_QUEUE Database Tables |
| com.tibco.bx.bpel.bg.moduleCleanup.interval | Used to clean up any modules from the database that have been marked for deletion. For example, the last instance of a module has been migrated or completed so that the module can now be removed. Specified as either of the following:
Default = P10 (minimum is P5) |
| com.tibco.bx.bpel.bg.pendingMsgProcessor.interval | Specifies how frequently pending messages are cleaned up. Specified as either of the following:
Default = P30 |
| com.tibco.bx.bpel.bg.pendingMsgProcessor.numMsgs | The batch size for pending-message cleanup jobs, that is, the number of expired signals that are to be processed at one time.
Default = 500 |
| com.tibco.bx.bpel.bg.unclaimedMsgProcessor.interval | If system-wide locking is disabled (com.tibco.bx.lockOperation=false), this property specifies how frequently a background job checks for, and processes, unclaimed messages. Specified as either of the following:
Default = P30 For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.bpel.bg.unclaimedMsgProcessor.numMsgs | If system-wide locking is disabled (com.tibco.bx.lockOperation=false), this property controls the maximum number of unclaimed messages that will be picked up per execution. The minimum is 50.
Default = 500 For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.bpel.maintenance.purgeProcess.interval | Used to automatically delete completed process instances, based on time, as follows:
Default = D1 (daily at 1 AM) Also see com.tibco.bx.autoDelete. |
| com.tibco.bx.engine.checkParms |
Prior to version 2.2.0 of ActiveMatrix BPM, if a process called a reusable sub-process, and the sub-process had mandatory parameters, the system was not checking to ensure that the parameters contained a value. The sub-process would start without error. However, it could result in an error later in the sub-process. The issue described above was resolved in version 2.2.0. Mandatory parameters are now checked to ensure they are not null. If the main process calls a sub-process, and there are mandatory input parameters to the sub-process, the sub-process is not started. The com.tibco.bx.engine.checkParms property can be set to "no" to override this stricter enforcement of mandatory parameters. This can be used if you are using a pre-2.2.0 application that worked fine previously, but has issues with the stricter enforcement of mandatory parameters. |
| com.tibco.bx.engine.clearInMemoryTrackers | If true, an in-memory instance row is cleared from the PVM_INMEM_PROC_TRACKER table when the sub-process task that started it has completed.
Default = true |
| com.tibco.bx.engine.recovery.failure.threshold | The number of seconds after which a process engine is considered failed and needs to be recovered.
Default = 30 |
| com.tibco.bx.engine.threadPool.size | Specifies the number of PE threads in the pool for processing work. Note that this property setting overrides the
engineThreadCount value set on the
amx.bpm.app in ActiveMatrix Administrator.
Default = 5 |
| com.tibco.bx.filterByOrgs | If a resource is mapped to more than six organizations, and that resource starts a process instance, BX_TOO_MANY_ORG_IDS is written to the BPM.log. This property specifies whether BX_TOO_MANY_ORG_IDS is shown as a warning or an error. The valid settings are: |
| com.tibco.bx.groupRQ.batchSize | Controls number of rows from PVM_REQUEST_QUEUE to read in a batch.
Default = 25 Also see Configuring How Often the Process Engine Looks for Work Requests. |
| com.tibco.bx.groupRQ.fillLevel | Maximum number of items in the in-memory queue; will read batchSize items (see
com.tibco.bx.groupRQ.batchSize) until this is reached.
Default = 50 Also see Configuring How Often the Process Engine Looks for Work Requests. |
| com.tibco.bx.groupRQ.idleSleep | Number of milliseconds to sleep before trying again when no rows are found.
Default = 100 Also see Configuring How Often the Process Engine Looks for Work Requests. |
| com.tibco.bx.groupRQ.lowWaterLevel | The number of items in the in-memory queue, at which point the "PVM:DB Work Queue" is re-started.
Default = 10 Also see Configuring How Often the Process Engine Looks for Work Requests. |
| com.tibco.bx.lockOperation | Specifies whether system-wide locking is enabled:
Also see com.tibco.bx.bpel.bg.unclaimedMsgProcessor.interval and com.tibco.bx.bpel.bg.unclaimedMsgProcessor.numMsgs. For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.lockOperation.ModuleName | This is used in conjunction with
com.tibco.bx.lockPerOperation to specify locking at the module level. If
com.tibco.bx.lockPerOperation=true, this property can be set to true (to enable locking) or false (to disable locking) for the module specified in
ModuleName.
If this property is set (either true or false), it takes precedence over the com.tibco.bx.lockOperation.ModuleName.PortType.OperationName (see below), if specified. For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.lockOperation.ModuleName.PortType.OperationName | This is used in conjunction with
com.tibco.bx.lockPerOperation to specify locking at the operation level. If
com.tibco.bx.lockPerOperation=true, this property can be set to true (to enable locking) or false (to disable locking) for the operation specified in
OperationName. The
PortType must be in the form
{NamespaceURI}localPort.
Note that if the com.tibco.bx.lockOperation.ModuleName property (see above) is also specified, it takes precedence over this property. For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.lockPerOperation | If system-wide locking is enabled (that is,
com.tibco.bx.lockOperation=true), this property can be used to enable finer-grained control over locking. Set this property to true, then use either
com.tibco.bx.lockOperation.ModuleName or
com.tibco.bx.lockOperation.ModuleName.PortType.OperationName to specify locking at the module- or operation-level.
For more information, see Configuring Locking Operation on Retry When Receiving/Retrieving a Message. |
| com.tibco.bx.lockPerSignal | If signal definition locking is enabled (by setting
com.tibco.bx.lockSignal=true), this property can be used to enable finer-gained control over locking. Set this property to true, then use either
com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion or
com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion.signalName to enable signal locking at the application- or signal-level.
For more information see, Locking of Signal Definitions. |
| com.tibco.bx.lockSignal | Specifies whether locking is enabled on signal definitions.
Default = true For more information see, Locking of Signal Definitions. |
| com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion | If locking per signal is enabled (by setting
com.tibco.bx.lockPerSignal=true), this property can be used to enable signal locking at the application level, as follows:
com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion For more information see, Locking of Signal Definitions. |
| com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion.signalName | If locking per signal is enabled (by setting
com.tibco.bx.lockPerSignal=true), this property can be used to enable signal locking at the signal level, as follows:
com.tibco.bx.lockSignal.SignalAppName.SignalAppVersion.signalName For more information see, Locking of Signal Definitions. |
| com.tibco.bx.management.queryMaxResultSize | The maximum number of process templates that are displayed in the TIBCO Workspace Start Process Instance dialog.
Default = 500 For more information, see "Setting How Many Templates Can Be Listed in the Workspace "Start Process Instance" Dialog" in the TIBCO ActiveMatrix BPM Administration guide. |
| com.tibco.bx.maxCancelChildrenBatchSize | The number of process instances to cancel in a batch.
Default = 100 |
| com.tibco.bx.maxGlobalSignalListenerCount | The number of global signal event handlers that can listen on the same signal definition with the same correlation.
Default = 100 For more information, see Maximum Listener Count. |
| com.tibco.bx.maxTasksPerInstance | The maximum number of tasks that can be generated by a process instance. If this threshold is reached, the process instance is halted.
Default = 1000 For more information, see Configuring the Maximum Number of Tasks per Process Instance. |
| com.tibco.bx.showExtendedPriorities | By default, process instance priorities are shown in the event log as LOW, NORMAL, HIGH, or EXCEPTIONAL (which equate to 100, 200, 300, or 400, respectively). If a process instance priority is set to a value other than 100, 200, 300, or 400, it is shown in the event log as "CUSTOM(value)".
If this property is set to "yes", and a process instance priority is set to a value other than 100, 200, 300, or 400), that integer value is shown in the event log, rather than CUSTOM(value). Note that this only applies to process instances whose priorities are set after this property is set to "yes". Process instances whose priorities were set to a value other than 100, 200, 300, or 400 prior to setting this property to "yes" still display as CUSTOM(value). Default = no |
| com.tibco.bx.suspendOnError | If this property is set to "yes", and an activity throws a Java exception, Process Manager checks to see if a number of criteria are true:
If all of these criteria are satisfied, the current transaction is rolled back and the process instance is placed in the SUSPENDED state. Otherwise: Default = yes For more information, see "Configuration of Error Handling Behavior for Process Instances" in the TIBCO ActiveMatrix BPM Administration guide. |
| com.tibco.pvm.txVerification.enable | This property provides a workaround for a Microsoft SQL Server defect where a commit returns successfully (in XA mode) even though the transaction has not completed. This defect can result in duplicate work items.
If this property is set to "yes", a delay is introduced between transactions to ensure that the previous transaction has committed completely. Default = yes (if Microsoft SQL Server is being used, otherwise the default = no) If this property is set to "yes", the properties listed below can be used to configure the transaction delay. Also see "Setting Transaction Verification Property (SQL Server Only)" in the TIBCO ActiveMatrix BPM Installation and Configuration Guide. |
| com.tibco.pvm.txVerification.retryInterval
com.tibco.pvm.txVerification.timeout com.tibco.pvm.txVerification.warn |
These properties are used in conjunction with the
com.tibco.pvm.txVerification.enable property (see above) to configure the transaction delay.
If the check fails after the retryInterval, "Unable to verify transaction [%s], suspending the process" is logged. |
Configuring JVM Properties on the BPMNode
JVM Properties are configured using TIBCO ActiveMatrix Administrator. Use the following procedure to add a new property, delete an existing property, or modify the value of an existing property.
- In ActiveMatrix Administrator, select .
- In the Nodes list, select BPMNode.
- In the lower pane, select the Configuration tab.
- Select the
JVM Configuration link.
The Properties section lists the existing JVM properties defined for the BPMNode. From this section, you can:
- Add a new JVM property by clicking Add, then entering the name and value of the property.
- Delete an existing JVM property by selecting the property in the list, then clicking Delete.
- Modify the value of an existing JVM property by selecting the property in the list, then changing the value in the Value field.
- Click Save.
- Stop, then restart the BPMNode to have your changes take effect: