Network Deployment (Distributed operating systems), v8.0 > Reference > Custom properties


Service integration custom properties

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

We 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 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 Bytes
Default 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 Bytes
Default 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 we have enabled automatic restart in the monitoring policy for the server, the server restarts. The messaging engine starts when an appropriate server is available.

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.

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 Milliseconds
Default 900000 (15 minutes)


sib.msgstore.jdbcResAuthForConnections

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

Data type String
Default 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.

Data type Milliseconds
Default 2000 (2 seconds)


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. We 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 the 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.

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 Integer
Default 100


sib.trm.retry

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

Data type Seconds
Default 30


sib.wsrm.tokenLockTimeout

This property affects WS-ReliableMessaging managed qualities of service. Set this property on the messaging engine 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 the 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 the 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.

Data type Milliseconds
Default 600000 (10 minutes)

Secure transport configuration requirements
Set tuning properties of a messaging engine
Set tuning properties by editing the sib.properties file
Tune one-phase commit optimization
Configure messaging engine and server behavior when a data store connection is lost
Add mediation context information
Tune the detection of database connection loss
Controlling the memory buffers used by a messaging engine
Set tuning properties for a mediation
WS-ReliableMessaging policy binding

+

Search Tips   |   Advanced Search