IBM Support

The most commonly used Service Integration Bus custom properties in WebSphere Application Server

Technical Blog Post


Abstract

The most commonly used Service Integration Bus custom properties in WebSphere Application Server

Body

 

You might want to  configure Service Integration Bus custom properties to suit your business requirements and your environment. There are 2 ways to configure the Service Integration Bus custom parameters:

1. Using admin console
2. Using the sib.properties file

Note: Properties set with the administrative console take precedence over properties set in the sib.properties file.


Procedure using Admin Console:
In the navigation pane, click:

Service integration -> Buses -> bus_name -> [Topology] Messaging engines -> engine_name -> [Additional Properties] Custom properties .

    Type the name of the property that you want to set.
    Type the value that you want to set for that property.
    Click OK.
    Save your changes to the master configuration.
    Restart the messaging engine for the changes to take effect.


Procedure using sib.properties file:

1. Navigate to the profile_root/properties directory, where profile_root is the directory in which profile-specific information is stored.
2. If the directory does not contain a sib.properties file, then copy the template sib.properties files from the app_server_root/properties directory, where app_server_root is the root directory for the installation of WebSphere Application Server (WAS).
3. Using a text editor, open the sib.properties file and add the name and value of the property that you want to set. The format is property_name=value.

For example:
 
com.ibm.ws.sib.jfapchannel.HEARTBEAT_INTERVAL=300
com.ibm.ws.sib.jfapchannel.HEARTBEAT_TIMEOUT=15
sib.trm.retry=60

Restart the messaging engine for the changes to take effect.

This is the list of most commonly used Service Integration Bus custom properties in WebSphere Application Server:

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

2. sib.trm.linger

This is the time for messaging engine lookup delay so that the Work Load Manager (WLM) waits for a longer period of time before returning an error. If your environment is heavily loaded, the WLM might not be able to locate the running messaging engine within three seconds. In this case, check if there are any hung threads in the SystemOut.log, and resolve them if possible. Next, consider increasing the value of sib.trm.linger from three to give the HA manager more time to locate a messaging engine.

    The default value is 3 seconds.


3. In SIB we use Heartbeats to check that connections are still valid. There are 2 properties you can tune for Service Integration Bus Heartbeats according to your environment.

    a) com.ibm.ws.sib.jfapchannel.HEARTBEAT_INTERVAL
        Its default value is 300 seconds (5 minutes)

    b) com.ibm.ws.sib.jfapchannel.HEARTBEAT_TIMEOUT
        Its default value is 7 seconds.

HEARTBEAT_INTERVAL is the amount of a connection-idle time, in seconds, before the WebSphere Service Integration Bus (SIBus) messaging engine attempts to solicit a response from it's peer to check that the peer is still active. Its default value is 300 seconds (5 minutes).

HEARTBEAT_TIMEOUT is the amount of time, in seconds, to wait for a response from a peer after deciding to check that the peer is still alive. The default value is 7 seconds.  In other words, by default if a connection is idle for 5 minutes, a heartbeat request is sent. If no response to this heartbeat request is received after 7 seconds, the connection is closed.

It is worth noting that the sum of both of these values determine the maximum amount of time that it can take to discover that some type of network failures have occurred.

Heartbeat values are negotiated between the messaging engine and the connecting process. Therefore, it is important that the settings are made on both sides of the connection. Otherwise, the negotiation between the two may cause the change to be ignored.

The 7 second default Heartbeat Timeout value is often too short for some installations that may have busy systems.  On a busy system a response to a heartbeat request may require more than 7 seconds. We often suggest increasing this value to 30 seconds to give more time for busy systems to respond to these requests.

The following line could be used to reduce the heartbeat interval from 5 minutes to 1 minute (to account for an idle timeout on a firewall*):

com.ibm.ws.sib.jfapchannel.HEARTBEAT_INTERVAL=60

The following line could be used to increase the heartbeat timeout from 7 seconds to 2 minutes (to account for overloaded remote servers**):

com.ibm.ws.sib.jfapchannel.HEARTBEAT_TIMEOUT=120

Note that tuning the timeout does not address the root cause of any network problems, or problems with the remote server which caused it to fail to respond to the heartbeat request.

When a firewall idle timeout is set to a value less than the configured heartbeat interval, idle connections are terminated before the heartbeat interval elapses. In such cases, the heartbeat interval should be reduced to less than the idle timeout of the firewall.

  
4. sib.msgstore.jdbcFailoverOnDBConnectionLoss

By default (in WAS 7 and 8) this parameter is set to 'true' (sib.msgstore.jdbcFailoverOnDBConnectionLoss=true). This means that if the connection between the messaging engine and its data store is lost the server the messaging engine was running on will be terminated almost immediately (look for a "panic" message) and the messaging engine will immediately failover to another server in the messaging cluster. THIS IS DONE TO PREVENT A LOSS OF MESSAGING DATA! The messaging engine will then try for 15 minutes to get a new lock on its data store.

If you set this value to "false" (sib.msgstore.jdbcFailoverOnDBConnectionLoss=false) then the server the messaging engine is running on will not immediately terminate and the messaging engine will try for 15 minutes to get a lock on its data store. THIS TIME SPENT TRYING TO GET A NEW CONNECTION COULD RESULT IN DATA LOSS! If it cannot get a lock on its data store then the server will terminate and the messaging engine will failover to another server in the messaging cluster and try again for 15 minutes to get a lock on its data store.

See "Configuring messaging engine and server behavior when a data store connection is lost"

NOTE: In WAS 8.5 the behavior that occurs when a connection to the database is lost has changed!  In WAS 8.5 and later:

  • The JVM which is hosting the messaging engine will NOT fail with Panic condition. High availability manager  just stop the messaging engine and fail over the messaging engine to the next available JVM in that cluster. As JVM is not terminated all other WebSphere applications continue to run on that JVM.
  • If you have enabled the "Restrict long running locks" feature the failover messaging engine instance will be able to get a new lock on the database tables almost immediately and start the messaging engine with out any issues.


5. 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. This setting allows you to tune how long we wait for our initial connection to the datastore (allowing you to delay the attempt to get a connection).

The default value is 900000 (15 minutes). This time includes the time required to establish a connection to the database and to obtain the required table locks.


6. 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. This setting defines how long we should attempt to gain a connection from the data source connection pool before giving up.
    
This property is the time, in milliseconds, to wait between attempts to connect to the data store. The default value is 2000 (2 seconds). 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.


7. sib.msgstore.jdbcConnectionRetryMaximumDuration

This parameter defines the time the ME can try to connect to the Datastore if the connection to the database was lost. This parameter is set in milliseconds and the default value is 90000 milliseconds (15 minutes). Increasing this value would cause the ME to attempt trying to connect to the datastore for a longer duration of time. NOTE THAT THIS COULD RESULT IN DATA LOSS BECAUSE APPLICATIONS MAY CONTINUE TO SEND PERSISTENT MESSAGES TO THE MESSAGING ENGINE AND THERE WILL BE NO WAY TO STORE THEM!                  


In addition to the above most commonly used Service Integration Bus custom properties some other custom properties are available and these are available here:
 

 


NOTE: If you are running WAS 8.5 or higher and have the "Restrict long running locks" feature enabled most of the database connection parameters above will be irrelevant. The messaging engine should be able to get the new lock almost immediately.

 

 

 

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]

UID

ibm11080435