Service integration custom properties

Use custom properties to configure advanced settings for service integration objects such as messaging engines.

You can use the custom properties page to define the following service integration properties:

sib.msgstore.cachedDataBufferSize

The size in bytes of the data buffer that the messaging engine uses to contain data for which the quality of service attribute is better than best effort nonpersistent and that is held in the data store. The default value is 320000, which is approximately 320 kilobytes.

The purpose of the cached data buffer is to optimize the performance of the messaging engine by caching in memory the data that the messaging engine might otherwise have to read from the data store. As it writes data to the data store and reads from the data store, the messaging engine attempts to add that data to the cached data buffer. The messaging engine might discard data already in the buffer to make space.

Data type	Default
Bytes	40000000

sib.msgstore.discardableDataBufferSize

The size in bytes of the data buffer that the messaging engine uses to contain data for which the quality of service attribute is best effort nonpersistent. The default value is 320000, which is approximately 320 kilobytes.

The discardable data buffer contains all data for which the quality of service attribute is best effort nonpersistent. That data comprises both data that is involved in active transactions, and any other best effort nonpersistent data that the messaging engine has neither discarded nor consumed. The messaging engine holds this data entirely within this memory buffer and never writes the data to the data store. When the messaging engine adds data to the discardable data buffer, for example when the messaging engine receives a best effort nonpersistent message from a client, the messaging engine might discard data already in the buffer to make space. The messaging engine can discard only data that is not involved in active transactions. This behavior enables the messaging engine to discard best effort nonpersistent messages.

Increasing the size of the discardable data buffer allows more best effort nonpersistent data to be handled before the messaging engine begins to discard messages.

If the messaging engine attempts to add data to the discardable data buffer when insufficient space remains after discarding all the data that is not involved in active transactions, the messaging engine throws a com.ibm.ws.sib.msgstore.OutOfCacheSpace exception. Client applications can catch this exception, wrapped inside API-specific exceptions such as javax.jms.JMSException.

Data type	Default
Bytes	1280000

sib.msgstore.jdbcFailoverOnDBConnectionLoss

The property determines the behavior of the messaging engine and its hosting server in the event that the connection to the data store is lost.

Property value	Behavior when the data store connection is lost
true (default)	The high availability manager stops the messaging engine and its hosting application server when the next core group service Is alive check takes place (the default value is 120 seconds). If a node agent is monitoring the server, and you have enabled automatic restart in the monitoring policy for the server, the server restarts. The messaging engine starts when an appropriate server is available. Note: Messages with a reliability level that is lower than assured persistent might be accepted by the messaging engine during the interval between Is alive checks, and might be lost.
false	The messaging engine continues to run and accept work, and periodically attempts to regain the connection to the data store. If work continues to be submitted to the messaging engine while the data store is unavailable, the results can be unpredictable, and the messaging engine can be in an inconsistent state when the data store connection is restored. Note: If work continues to be submitted to the messaging engine, even nonpersistent messaging can fail because the messaging engine might need to use the data store, for example to allocate a unique ID to a message, or to move nonpersistent messages out of memory.

Property value

Behavior when the data store connection is lost

true (default)

The high availability manager stops the messaging engine and its hosting application server when the next core group service Is alive check takes place (the default value is 120 seconds). If a node agent is monitoring the server, and you have enabled automatic restart in the monitoring policy for the server, the server restarts. The messaging engine starts when an appropriate server is available.

Note: Messages with a reliability level that is lower than assured persistent might be accepted by the messaging engine during the interval between Is alive checks, and might be lost.

false

The messaging engine continues to run and accept work, and periodically attempts to regain the connection to the data store. If work continues to be submitted to the messaging engine while the data store is unavailable, the results can be unpredictable, and the messaging engine can be in an inconsistent state when the data store connection is restored.

Note: If work continues to be submitted to the messaging engine, even nonpersistent messaging can fail because the messaging engine might need to use the data store, for example to allocate a unique ID to a message, or to move nonpersistent messages out of memory.

sib.msgstore.jdbcInitialDatasourceWaitTimeout

The time, in milliseconds, to wait for the data store to become available. This time includes the time required to establish a connection to the database and to obtain the required table locks.

Data type	Default
Milliseconds	900000 (15 minutes)

sib.msgstore.jdbcResAuthForConnections

The messaging engine resource authorization mechanism used when sharing connections. Default value is Container.

Data type	Default
String	Container

sib.msgstore.jdbcStaleConnectionRetryDelay

The time, in milliseconds, to wait between attempts to connect to the data store.

For example, if you set the sib.msgstore.jdbcInitialDatasourceWaitTimeout property to 600000, and the sib.msgstore.jdbcStaleConnectionRetryDelay property to 3000, the messaging engine will attempt to connect every 3 seconds for 10 minutes.

Information	Value
Data type	Milliseconds
Default	2000 (2 seconds)

sib.meEnableInstanceOnFailure

This property determines whether the server will attempt to restart a messaging engine that has encountered an error because it lost its connection to the datastore.

For example, if you set the sib.meEnableInstanceOnFailure property value to true, the disabled messaging engine will attempt to enable itself after 30 seconds.

Information	Value
Data type	Boolean
Default	True

sib.meAutoReenablePeriod

Specifies the time, in milliseconds, to wait before an attempt is made to restart the messaging engine that is being restarted because the sib.meEnableInstanceOnFailure property has been set to true.

For example, if you set the sib.meAutoReenablePeriod property value of 40000, the server will attempt to restart the messaging engine after 40 seconds.

Information	Value
Data type	Milliseconds
Default	30000 (30 seconds)

sib.meReenableCount

Specifies the number of times that the server will attempt to automatically restart a messaging engine that is being restarted because the sib.meEnableInstanceOnFailure property is set to true.

For example, if you set the sib.meReenableCount property to a value of 7, the server will attempt to restart messaging engine 7 times. If it fails to successfully restart the messaging engine in these 7 attempts the SIB service is stopped and no further attempts to restart the messaging engine can be made until the service is started again.

Information	Value
Data type	Integer
Default	5

sib.processor.maxReconstituteThreadpoolSize

Specifies the number of threads used to load destinations concurrently when the messaging engine is started. In case your database does not support parallel multiple reads by multiple threads, then you might set the property value to 1, so that contention among threads could be avoided.

Information	Value
Data type	Integer
Default	The number of cores present in the system.

sib.msgstore.storeFullWaitForCheckPoint

This property determines the action a messaging engine takes when a file store is full and applications try to send further messages.

When a file store is full, the messaging engine carries out a checkpoint of the log file to reconcile all message sends and receives since the last checkpoint. This process might take some time to complete. Between the time when the file store becomes full and the time when the checkpoint is complete, if applications try to send a message, the messaging engine throws the exception ObjectStoreFullException and issues message CWSOM1042E.

When an application thread that is sending a message finds that the file store is full, it requests a checkpoint. The default behavior, with the property value set to false, is that the application thread then throws the exception ObjectStoreFullException to the application immediately and returns. You can select an alternative behavior by setting the property value to true. With this property value, the application thread does not throw the exception, but waits until the checkpoint has completed. If the checkpoint frees space in the file store, the application thread proceeds and sends the messages before returning. If the file store is still full after the checkpoint, the application thread throws the exception to the application.

Set the property value to true, and make application threads wait for the checkpoint to be completed, if your applications delete all the messages in the file store, and so they logically know that the file store is no longer full. Although the applications must still wait until the checkpoint is complete, they do not receive exceptions while the checkpoint is being carried out, and they do not have to retry the send.

Information	Value
Data type	Boolean
Default	False

sib.msgstore.transactionSendLimit

The maximum number of operations that the messaging engine includes in each transaction. For example, each JMS send or receive is an operation that counts towards the transaction send limit. The default value is 100.

Data type	Default
Integer	100

sib.ra.zosMessageLockTimeout

The number of seconds that a message is locked in the messaging engine after that message has been submitted to Workload management (WLM) for z/OS® for delivery to a message-driven bean.

WLM allocates the message to a servant region, which creates a connection to the messaging engine. The servant region then consumes the message and passes it to the onMessage method of the message-driven bean.

If the servant region fails to connect to the messaging engine and consume the message before passing it to the message-driven bean, the message remains locked until the timeout value is reached. When the timeout is reached, the message is unlocked and delivery is retried.

During startup of an application server, if WLM delivers a message to a servant region before the infrastructure that is required to connect to the messaging engine is available, that servant region might fail to connect to a messaging engine. Connection failures of this type are indicated by CWSIV1052W entries in the job log of the servant region. If you see such entries in the job log, and you have locked messages, consider using this property to make the Message Lock Timeout shorter.

Data type	Default
Seconds	300

sib.trm.retry

The messaging engine to messaging engine connection retry interval, in seconds. The retry interval is the time delay between attempts to contact neighboring messaging engines with which communications exist. The default retry interval is 30 seconds.

Data type	Default
Seconds	30

sib.wsrm.tokenLockTimeout

This property affects WS-ReliableMessaging managed qualities of service. Set this property on the messaging engine that is specified in the policy binding for the WS-ReliableMessaging application.

This property is the amount of time, in milliseconds, that a lock is held on a WS-ReliableMessaging message. If a server fails while processing a message, the lock is released at the end of this timeout period, so that other servers can continue the processing. If the original server recovers before the timeout period ends, it continues processing the message. The lock is released at the end of the timeout period even if the message is still being processed.

If your system is processing large messages, you might want to increase the value of this property. For example, if a message takes 12 minutes to process, the lock is released 2 minutes before processing is complete. To avoid this situation, change the property to a value that is greater than 12 minutes.

If your system is processing small messages, you might want to decrease the value of this property, so that if a failure occurs the lock is released more quickly, and other servers can continue the processing without delay.

Note:

If a servant region ends abnormally while processing a message, the control region starts a new servant region, which must wait for the message lock to be released before it can continue processing the message. If the servant region is inactive for too long, the control region ends it and starts another servant region. Also, if the servant region takes a long time to process a message, the control region might perceive the servant region to be inactive, and end it.

The amount of time that a servant region can remain inactive until the control region ends it is affected by various timeouts, such as the control_region_wlm_dispatch_timeout property. Examine the configuration of your system to determine what this period of time is for that system.

To avoid the control region ending the servant region before the message has been processed, set the value of the token lock timeout property to be less than the amount of time that the servant region can be inactive.

Information	Value
Data type	Milliseconds
Default	600000 (10 minutes)