+

Search Tips   |   Advanced Search

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 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 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 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 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

The property determines whether the disabled messaging engine must be enabled again automatically in case the messaging engine loses connectivity to the data store.

For example, if 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.processor.maxReconstituteThreadpoolSize

Specifies the number of threads used to load destinations concurrently when the messaging engine is started. In case the 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. 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.

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 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 we see such entries in the job log, and we 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 left 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 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.

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 the 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)


(v8552) sib.property.isMECritical

Mark a messaging engine as critical. This property is used in conjunction with the adjunct_region_start_sib_abend, adjunct_region_start_sib_waittime, and adjunct_region_start_sib_abend environment variables. See the topic Application server custom properties for z/OS for a description of these environment variables.

Information Value
Data type Boolean
Default False


Related concepts

  • Secure transport configuration requirements


    Related tasks

  • 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

  • Timeout properties summary


    Related information:

  • WS-ReliableMessaging policy binding Reference topic