The Java Message Service (JMS) is a messaging standard that allows application components based on the Java Platform Enterprise Edition (Java EE) to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.
As per FIXEdge Java, JMS endpoints allow you to establish a connection with JMS-message providers and receive/send data from/to them. JMS endpoints can work with queues and topics. Each endpoint has a unique name. JMS endpoints only route messages in one way: when they are configured as producers or consumers.
During FIXEdge Java server start-up, endpoints, which are defined in the jms-adaptor.properties, are initiated. The list of active endpoints is defined by the property
jms.adaptor.ClientNames is empty, none of the clients are active.
To add a JMS endpoint to a jms-adaptor.properties file it needs to:
- Define JMS connection configuration. JMS connection properties have a prefix jms.adaptor.Connection.[ConnectionName], where [ConnectionName] is the unique name of this connection, which used to link it with JMS endpoint configuration. JMS connection has a set of predefined properties (see the table below) but can be extended with custom ones (see samples below).
- Define JMS endpoint configuration and add its name to the
1. Configuration properties
The JMS adaptor is configured by means of the following properties:
|jms.adaptor.ClientNames||A comma-delimited list of JMS endpoints.|
A separate configuration section for each listed client should be specified.
|jms.adaptor.ConnectionNames||A comma-delimited list of TA connections.|
A separate configuration section for each listed connection should be specified.
JNDI option. The fully qualified class name of the factory class that will create the initial context. An initial context is the starting point for naming operations.
|C, required if JNDI mechanism is used|
|jms.adaptor.Connection.[ConnectionName].ProviderURI||JMS provider URI that defines where the connection that is created will connect to, as well as the protocol that should be used, for example, TCP/IP. Additionally, configuration information can be encoded in the URI.||Y|
|jms.adaptor.Connection.[ConnectionName].ConnectionFactory||JNDI option. The connection factory object name in the JNDI objects store.||C, required if JNDI mechanism is used|
Enables or disables the reconnect procedure for connection restore.
This parameter is used for JMS brokers that don't support the failover mechanism.
|jms.adaptor.Connection.[ConnectionName].ReconnectTries||Number of reconnect tries or -1 for an infinite number of attempts||N||3|
|jms.adaptor.Connection.[ConnectionName].ReconnectInterval||Fixed interval in milliseconds between reconnection attempts||N||2000|
|jms.adaptor.Client.[ClientName].ConnectionName||Name of the primary connection used by the client. The connection should be registered in the ||Y|
|jms.adaptor.Client.[ClientName].StorageDir||Directory where the persistence file is stored in case of a communication problem.||Y, if the persistent mode is enabled|
Session messaging mode:
Queue - Point-To-Point. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire.Topic - Publish/Subscribe. In a pub/sub product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing messages arriving from a topic’s multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.
|jms.adaptor.Client.[ClientName].DestinationURI||URI of session destination (queue/topic name)||Y|
Specifies whether the sent messages are lost if the JMS provider fails.
Persist - instructs the JMS provider to take extra care to ensure that a message is not lost in transit in case of a JMS provider failure. A message sent with this delivery mode is logged to stable storage when it is sent.
NoPersist - does not require the JMS provider to store the message or otherwise guarantee that it is not lost if the provider fails.
NOTE: used only for Producer sessions.
|jms.adaptor.JMSTA.Client.[ClientName].TimeToLive||This value defines a message expiration time (in milliseconds) that is the sum of the message's time-to-live and the GMT when it is sent. (For transacted sends, this is the time at which the client sends the message, not the time when the transaction is committed.) Setting the parameter value to "0" will lead to infinite TTL.||Y||3000|
Defines the mode in which the JMS session will acknowledge the messages that it receives and dispatches.
Auto - the session automatically acknowledges a client's receipt of a message either when the session has successfully returned from a call to receive or when the message listener the session has called to process the message successfully returns.
Client - the client acknowledges a consumed message by calling the message's acknowledge method. Acknowledging a consumed message acknowledges all messages that the session has consumed. When client acknowledgment mode is used, a client may build up a large number of unacknowledged messages while attempting to process them.
DupsOk - instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should only be used by consumers that can tolerate duplicate messages. The use of this mode can reduce session overhead by minimizing the work the session does to prevent duplicates.
JMS Message type used for the session.
Bytes - A stream of interpreted bytes. This message type is for literally encoding a body to match an existing message format.
Text - Data is stored as a string. This message type is useful for exchanging simple text messages and for more complex character data, such as XML documents.
Custom - The ability to use your own message type. This message type is useful for adaptation to already existing systems. For this message type, the property jms.adaptor.Client.[ClientName].CustomMessageType is required.
Class of custom message type implementation. This should be the implementation of one of the interfaces:
NOTE: used only for Custom message type
|Y, if MessageType is Custom|
Determines whether the sending/consuming of messages in the session is transacted.
true - transacted.
false - not transacted. The value is used by default.
Max number of messages for one transaction. Take the available number of messages from the queue but no more than the amount specified in this property.
NOTE: used only if transacted is enabled.
|jms.adaptor.Client.[ClientName].QueueSize||Max number of messages in the outgoing endpoint queue. Messages are queued until successfully sent. Waits for space to become available if the queue is full.||N||100|
Store messages in the file until committed. It allows to restore and send messages after a sudden cardiac application.
true – persistent queue.false – in-memory queue. Faster but less safe; some messages may be lost after restart.
After reaching this size, the endpoint waits until the queue is empty to truncate the file. File size in Mbytes.
NOTE: used only for the persistent queue.
After reaching this size, the endpoint truncates the file and overwrites the messages that are queued. File size in Mbytes.
NOTE: used only for the persistent queue.
Durable topic subscriptions allow receiving messages published while the subscriber is not active. Durable subscriptions offer the reliability of queues to the publish/subscribe message domain.
true - Subscription is durable.
false - Subscription is not durable.
|jms.adaptor.Client.[ClientName].DurableSubscriptionName||Durable subscription name.||Y, required if DurableSubscription set to true.|
Number of JMS connections.
The endpoint will open a given amount of connections to the JMS server for the given session to send simultaneously.
NOTE: If the number of connections is greater than 1, there is no guarantee that messages will be placed into JMS in the same order they were received by the endpoint.
The number of threads per JMS connection. The endpoint will open a given amount of JMS sessions for each JMS connection to send simultaneously.
NOTE: If the number of threads per connection is greater than 1, there is no guaranty that messages will be placed into JMS in the same order they were received by the adapter.
NOTE: All changes in the properties file are applied only after FixEdge Java server restart.
2. Sample Configuration
2.1. Sample configuration for ActiveMQ vendor
Make sure that activemq-client.jar is present in the /lib directory.
Typical JMS endpoint parameters in the jms-adaptor.properties:
NOTE: jms.adaptor.Connection.LocalActiveMQConnection.ProviderURI = tcp://localhost:61616 - host:port of Apache ActiveMQ Message Broker.
2.2 Configuration for TIBCO EMS vendor
Copy the appropriate TIBCO JMS client library (tibjms.jar) from the TIBCO EMS installation /lib directory.
Typical consumer connection parameters in the FIXEdge.properties:
Typical JMS consumer endpoint parameters in the jms-adaptor.properties: