Administering JMS transport optimization
The flow of business information from adapters to the
server, as well, as from the server to adapters, is a vital component
of the InterChange Server Express functionality. With the marked
increase in the use of JMS Transport, enhancements were necessary
to ensure the highest quality in performance, throughputs and scalability.
InterChange Server Express stores events in a persistent storage
for recovery purposes. In a non-optimized state, this storage could
be very costly, especially if the business object is expansive.
In an optimized state, the event is left in the message queue and
referenced in the database. When all event subscribers have completed their
work, the message is deleted from the queue.
By synchronizing information in the critical sections, events
can be retrieved sequentially from the queue, ensuring a retainable
event sequence as well as a scalable server in a multi-processor
environment.
In order to achieve JMS Transport optimization, the InterChange
Server Express provides the following enhancements:
- Improve caching - queue objects are cached
within the sender, enhancing adapter performance
- Batch database operations - business object
events are accumulated in an ordered list and then persisted together
in a batch operation, reducing the performance issues raised by
frequent database operations
- Optimize JMS recovery - increase the event
persistence performance, speed recovery operations and adapter response
This section covers the following topics:
Optimization versus non-optimization
Steps for activating and de-activating optimization
Optimization versus non-optimization
Although message transport is now optimized, there is
also a need for transport to run in a non-optimized state, dependant
upon business need. Switching from optimized to non-optimized allows
users to swap messaging providers, if necessary, to accommodate
the needs of their vendors.
You may opt to use a non-optimized state when business object
events are small in size, or when database overhead is insignificant.
However, prior to switching between an optimized and a non-optimized
state you must wait until all queued events are recovered. Events
running in an optimized state cannot be redelivered to InterChange
Server Express in a non-optimized state.
Note:
Optimization is designed to have minimal impact
on in-bound service calls and Long Lived Business Process (LLBP)
events, which will both continue to process as non-optimized events.
This is possible since the optimized state can process both optimized
and non-optimized events.
Steps for activating and de-activating optimization
Perform the following steps to activate and de-activate
JMS transport optimization:
- During the connector configuration, select the check box for
JMS Optimization.
- Set the value of the following connector properties. Once set,
the connector configuration will upgrade the configuration files.
- jms.TransportOptimized - True delivers events through optimized WIP.
- jms.ListenerConcurrency - specifies the number of concurrent listeners for
JMS transport. This property appears whenjms.TransportOptimized is set to True.
Note:
If JMS is set as the transport, the default value
for the jms.TransportOptimized property is False. When jms.TransportOptimized is set to True, the JMS provider (jms.FactoryClassName) must be IBM MQ.
- To switch back to the non-optimized state, first ensure that
the server is not currently processing any events and the delivery
queue is clean. If you attempt to switch from an optimized state
to a non-optimized state there are remaining events in the delivery
queue, an error will display when the connector deploys to InterChange
Server Express.
- Clear the check box for JMS Optimization.
- Set the value of the following connector properties. Once set,
the connector configuration will upgrade the configuration files.
- jms.TransportOptimized - False delivers events through non-optimized WIP.
