Network reliability is a common problem faced in designing a system spread over multiple machines. Enterprises across the world spend a large amount of their time and resources on network management, but it remains that network links cannot be 100% reliable. Mission-critical applications cannot afford to lose data in any eventuality and must always be built on this premise of unreliability. This requires that application programmers build a 'store and forward' layer in their Application infrastructures. This store and forward layer involve storing precious data upon detecting network loss, taking corrective action and resending the previously cached data again.
The JMS standard requires middleware to build the 'store and forward' mechanisms for consumers. This is achieved by marking a consumer 'durable'. If a consumer is unavailable, the server holds onto the messages. These messages are delivered when the consumer becomes available again. This standard JMS feature ensures that durable consumers always receive messages. JMS does not provide a similar level of reliability for a producer. If the server is unavailable the send mechanism of the producer fails, resulting in an appropriate exception. This forces applications to implement 'store' on the client side and transfer this data when connectivity is restored.
FioranoMQ enhances the capability of JMS support to provide the 'store and forward' function at the client end as well (in addition to the durable consumers on the server). This function allows JMS applications to continue all publish operations even if the server is unavailable, freeing up applications from all network related problems. A network disruption is thus not visible for a JMS application built over FioranoMQ.
Topics covered are as follows:
Overview
FioranoMQ introduces the concept of a 'Durable Connection'. A Durable Connection remains connected to the FioranoMQ Server at all time. Applications using durable connections do not have to store, re-connect and then forward stored messages to the server. This frees up the application from the complex task of building a 'store and forward' mechanism in application code.
The reliability of the underlying JMS transport is improved by durable connections. If the connection is lost and the application fails to transfer data, Durable Connections try to restore the connection automatically. This ensures that data is not lost in transit and is sent as soon as the connection is re-established. These activities are not visible to the application and are performed automatically by Fiorano's runtime library when it detects a connection failure. This makes the system reliable and robust even in the presence of network failures.
For example, consider a computer monitoring a steel mill. Real-time steel production information is sent every second to the main hub. The main hub uses this information to generate the desired results. If the connection between the Process computer and the Hub breaks, the 'send' mechanism will fail and an exception is thrown. Since this data is generated only once, the application stores this data on encountering the exception and then applies its resources to connect back to the server. This process adds a considerable load to the application.
In such cases, a Durable Connection comes to the rescue as it does all the hard work on behalf of the application. It automatically tries to re-establish the connection, stores the data in transit and sends it to the server as soon as the connection is restored.
Advantages
Durable Connections in FioranoMQ provide a host of advantages over standard JMS implementations:
Network Reliability
Durable connections provide network reliability by storing messages at the client end when the server is down – an essential feature required by most real-world systems.
Store and Forward Capabilities
Durable Connections enable 'store and forward' capabilities at the client level.
Transparent Reconnection Code
If Durable Connections are enabled, the client application does not hold the responsibility for reconnection. Reconnection is handled internally by FioranoMQ's runtime library.
Message Browsing of Persisted Messages
FioranoMQ provides a Message Browser which allows messages stored in the data store of the client, to be browsed.
No Vendor Lock-in
Connection revalidation logic is transparent to the client application and is handled by Fiorano's runtime library. Reconnection code and other details do not have to be managed at the application level. Only the connection factory with AllowDurableConnection needs to be referred to. Client side persistence and reconnection code are handled in a transparent manner by Fiorano's runtime library.
Working of Durable Connection
A durable connection works like an ordinary connection as long as the connectivity is maintained with the FioranoMQ Server. If the underlying socket breaks, a durable connection performs the following activities:
- Initiates a thread that continuously tries to re-connect with the server.
- Initializes a 'store', on the local machine, to store (on the client side) any new messages published.
Both these activities are not visible to the client application and are performed automatically by FioranoMQ's runtime library. When a connection is restored, messages stored in the local store are automatically sent to the server.
Producer on a Durable Connection
A producer creating messages over a Durable Connection can send messages whether or not actively connected to the server. The runtime library automatically handles problems of connectivity. If the underlying connection breaks, the runtime library establishes a local cache of messages on the client's machine. This local cache stores messages published by the producer when disconnected from the server. The base directory of this local cache can be configured by the client application. A subdirectory for each connection using the cache is created in the base directory, where messages for particular connections are stored. The client application can use any number of Durable Connections over the same base directory. Once connectivity has been re-established via Fiorano's runtime library, messages stored in the local cache are transferred to the server. Messages are transferred in the same chronological order in which they were published.
An application is free to send messages to more than one JMS Destinations over a single Durable Connection. Producers can be created on transacted as well as non-transacted sessions.
Consumer on a Durable Connection
Since consumers themselves can be defined as "durable" by virtue of their definition within JMS standards, very little is required to be done to ensure messages are delivered to a consumer, even if it that consumer is temporarily unavailable. If the consumer is created over a Durable Connection, the Fiorano runtime library automatically manages reconnects to the server in case of network failures. Message delivery is restored when the connection is established again.
Enabling Durable Connections Support
The ability to create a durable connection with the server can be controlled at the server and at the application level. Durable connections can be enabled/disabled using Fiorano eStudio by:
- Creating new connections to the server
- Adding a new connection factory
Client side Message Cache
A Durable Connection creates a cache on the local machine, to allow a producer to send a message even if the server is unavailable. The configuration of the base directory is explained in the preceding section. Within the base directory, a subdirectory is created for each connection. The subdirectory takes the name of the Client ID of the durable connection.
For example, if the base directory for Durable Connection is: c:\\temp
db in myConnectionFactory, any connection created through myConnectionFactory creates its cache in c:\\temp
db. If there are two connections on the same machine, with clientIDs "client1" and "client2", the directory structure takes the format below:
c:\\temp
db
____ client1.ptp |
If Client ID is not set, FioranoMQ at runtime internally creates a Unique ID for that particular connection and a directory by the same name is created for client side caching. However, it is recommended that the Client ID should be set in all instances of use of Durable connections because: An application cannot transfer pending messages upon restart, as a new ID is generated for that connection. Since the ID is a complex string, it is difficult to use CSP Message Browser to browse for client side persisted messages. Messages sent by a client are identified by its clientID. If the client application is terminated, upon restart, the runtime library checks if there are any pending messages stored in the local cache of the connection. This check is performed on the basis of the client ID set on the connection. Pending messages are sent to the server. This operation is performed when the clientID is set by the application. If the application wishes to ignore previously cached messages, it needs to add the following flag in the Hash table passed as the environment to InitialContext used for looking up operations. "DONT_SEND_PREVIOUSLY_STORED_MESSAGES", "TRUE" Use the following API available in the connection if the client application needs to exercise control over the time at which pending messages are to be transmitted: When the preceding method is used on a connection, the runtime invocation sends all pending messages for that connection to the server. The preceding method is used to purge all messages in the local cache published on the associated connection. |
Serverless Environment
It might be necessary in certain situations to run the client application in a serverless environment. A serverless instance is when a client needs to connect to a server even if the server is not available. This might be necessary when it is essential that a client connect with a server in situations where there is a high probability that a server is down Consider the case of a cellular service provider. The service provider has an SMS gateway that interacts with mobile devices by acting as an interface between the JMS server and the mobile phone. The JMS server routes the data ahead. A user uses his mobile phone/PDA or any other hand-held device to send an SMS to another user. This message first reaches the gateway, which has the responsibility of routing this message to another gateway interacting with the mobile device of the recipient, through a JMS server. There is a possibility that the server was down at the time the message is to be forwarded. If such a situation arises, the SMS would be lost.
Alternatively, if the gateway receiving the message from the sender is considered to be a JMS client with Durable Connections enabled, then it stores messages locally when the server is down. This provides a robust and reliable solution where messages are stored in the local cache and subsequently re-routed through the server when it becomes available.
To enable a client application to run in a serverless environment, the below needs to be set in an application:
This allows client applications to run with Durable Connections enabled in serverless environments.
Sample Application
Sample applications are available in the following directories of the FioranoMQ installation:
- %FMQ Home%\fmq\samples\ptp\Durable Connections
- %FMQ Home%\fmq\samples\pubsub\Durable Connections
These samples can be downloaded from www.fiorano.com.
Relationship with Revalidate
In this model of Durable Connections, the client application does not hold the responsibility of reconnection. If Durable Connections is enabled, the entire process is handled internally by FioranoMQ's runtime library. If the client application has Durable Connections enabled, the client does not have to take care of the revalidation code if the server breaks down. The FioranoMQ runtime invocation detects network failure internally and starts a reconnection thread that reconnects client to the server when it's available.
PublishBehaviourInAutoRevalidation parameter in Connection factory:
This parameter defines the behavior of the publisher when the auto revalidation is enabled and the durable connections are disabled in the Server. A new publish call will either throw an exception, or block or ignore a message when there is a connection loss detected with the server. By default, the value of this parameter is - throw exception.
Details of this parameter can be found in FioranoMQ Reference Guide Chapter 1.
Relationship with CSP
Client Side Persistence is provided in the 6.0 version and above. Proprietary APIs of FioranoMQ are needed for CSP.
To enable durable connections, client side persistence does not need to be enabled. In CSP, the following had to be set in the client application to enable client side persistence:
In Durable Connections these steps do not need to be performed. The client applications can 'lookup' a ConnectionFactory that has information on the Durable Connection. The application proceeds to set a unique clientID for the connection upon which Durable Connections are to be enabled. This enables messages sent by the sender to be stored in the directory structure specified in the ConnectionFactory (or in the ".\CSPCache" directory) and sent to the server once the connection is revalidated. Fiorano's runtime library handles the above steps, internally.
To enable durable connections, the client application is set to allow durable Connection in the env as a property, while setting a client ID for the connection:
Messages get stored on the client machine either in the directory specified in the env variable or in ".\CSPCache". Calling an explicit setCSPConnectionID on the connection on which CSP has to be enabled is not required. The only requirement entails setting a ClientID for the connection to enable Durable Connections.
Constraints in Durable Connections
Ensure that unique Client IDs are used if more than one application needs to use the same local cache simultaneously.
Using the browser for Client-side persistence while an application is using the same local cache can result in the browser behaving abnormally. The Client-side persistence browser should not be used while an application is using the same local cache.
Messages can get redelivered with the appropriate JMSREDELIVERED flag set. Messages can get redelivered when, for example, data reaches the MQServer and the client loses connection before the server acknowledges the receipt of data.
The base Durable Connection directory cannot be added while creating the connection factory through the Admin GUI.