JMS Message Timeout

Previously, XML over JMS messages did not time out. This sometimes led to a situation where if the remote system was not running, or there was an error, a message remained waiting indefinitely for a response on the replyTo queue.

New timeout functionality has been introduced that can be controlled by setting the following four parameters (all times are in milliseconds):

•

ServerEngineConfigMBean.ResponseTimeout (Default: 20000) - This timeout controls how long a Web Service response should be awaited before dropping into one of the scenarios below.

•

ServerEngineConfigMBean.ConsumeTimeout (Default: 500) - In a scenario where a JMS Message fails to respond in a timely fashion (before the responseTimeout), the outgoing message is reconsumed in an attempt to keep iProcess Engine and the remote system in sync about which calls have been made. This timeout controls how long the TIBCO iProcess Web Services Plug-in waits to reconsume this message.

•

ServerEngineConfigMBean.DeadlockTimeout (Default: 240000) - In a scenario where the outgoing message could not be reconsumed, it is assumed that the remote system is working on the call but is very slow. This timeout controls how long the response is awaited in this scenario.

•

ServerEngineConfigMBean.ExpiryTimeout (Default: 0, off) - As an additional fail-safe, the outgoing JMS Message can have an expiry set on it, which will cause it to be removed from the queue if it is not processed by that time.

Note	This functionality requires that the server running Jetty and the JMS provider have synchronized clocks. Ignoring this requirement can cause undesirable behavior.