top of page

How to Ensure Reliable Messaging in Your Distributed Applications such as TCIB Online Banking

Java Message Service (JMS) facilitates reliable messaging between applications in today's interconnected world. However, like any distributed system, JMS can encounter issues such as network latency, system failures, or bottlenecks that can disrupt message delivery.


One critical aspect of managing these challenges is understanding and effectively handling JMS timeouts.





Importance of Setting Timeout Parameters

In JMS, a timeout refers to an application's duration for a response or acknowledgment from a messaging component before considering the operation failed or timed out. Timeouts ensure that applications remain responsive and can gracefully handle situations where message delivery may be delayed or unsuccessful.


Setting appropriate timeout values is crucial for ensuring the reliability and responsiveness of JMS-based applications. Here are a few reasons why:


Preventing Blocking: A JMS operation might block indefinitely without timeouts, leading to potential resource wastage and application unresponsiveness. By setting timeouts, applications can gracefully handle situations where responses are delayed or unavailable.


Failure Detection: Timeouts help detect failures within the messaging infrastructure or the network. Suppose a response is not received within the specified timeout period. In that case, the application can assume something went wrong and take appropriate action, such as retrying the operation or logging an error.


Resource Management: Setting appropriate timeouts also helps in efficient resource management. Timeouts ensure that resources are released promptly, preventing resource exhaustion and improving overall system scalability.


What are Common Timeout Parameters in JMS?

JMS provides various timeout parameters that can be configured based on the specific requirements of the application:


Connection Timeout: Specifies the maximum time the application waits while connecting with the messaging server. This timeout is crucial for handling network issues or server unavailability during the initial connection setup.


Session Timeout: Defines the maximum time a session remains idle before it's considered inactive and automatically closed by the JMS provider. 


Message Expiration Timeout: Indicates the maximum time a message is considered valid for delivery. If a message exceeds this timeout without being delivered, it's considered expired and may be discarded by the messaging system.


Request-Response Timeout: Relevant for request-response communication patterns, this timeout specifies the maximum time the sender waits for a response from the receiver. If no response is received within this period, the sender can handle the situation accordingly, such as retrying the operation or raising an error.


Best Practices for Handling Timeouts

Set Reasonable Timeout Values: Choose timeout values that balance responsiveness and reliability. Setting excessively short timeouts may lead to false positives, while overly long timeouts may degrade the application's responsiveness.


Implement Retry Mechanisms: In scenarios where timeouts occur, implement retry mechanisms to reattempt the operation. However, ensure that retries are performed judiciously to avoid overwhelming the messaging infrastructure or exacerbating the issue causing the timeout.


Monitor and Analyze Timeout Events: Implement comprehensive monitoring and logging mechanisms to track timeout events and analyze their root causes. This information can help identify performance bottlenecks, network issues, or other underlying message delivery problems.


Graceful Error Handling: Handle timeout events gracefully by providing informative error messages to users or logging detailed diagnostics for troubleshooting purposes. This helps in maintaining transparency and enables timely intervention in case of operational issues.


Solve JMS timeout errors in TCIB

In one of our projects we integrated Dynatrace to identify performance issues in the Temenos Connect Internet Banking platform TCIB. We've fixed one of the JMS-related issues by adding a reconnect-attempt parameter to the JMS queue definition.


<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa" reconnect-attempts="5"/>

Effective timeout management enhances the overall user experience and contributes to the stability and performance of the underlying infrastructure.


If you want more observability and performance-tuning best practices, please subscribe to our blog.


Keep up the great work! Happy Performance Engineering!

bottom of page