Objective

This document describes the delivery delay handling in the communication over the message queue in a multi server context.

General

The multi-server deployment of Product 360 is designed in a way to allow the highest form of independence of the servers in order to minimize any overhead which would be introduced through excessive locking mechanisms. Each server makes sure that concurrent data modification of the same object is synchronized. It's the nature of a highly scale able architecture like this that caches might be outdated for a short time as change events are delivered asynchronously. The application logic anticipates this delay and compensates by only persisting what is really modified - thus we do not update the database with old data and simultaneously keep the synchronization times to an absolute minimum.

If in that environment the client is connected to server 1 and the client does make a change to the persisted data values, and that change triggers a workflow instance that is communicating over the message queue with server 2, it might be that server 2 cannot see the persistence value changes done by server 1 in the case that the workflow execution and message transport is faster than the cache invalidation event.

To avoid that a workflow can run into this problem, there is a delivery delay introduced for outgoing queue messages to the workflow. The delivery delay ensures the Informatica BPM server will get the message only after the delivery delay has passed and not earlier. The default setting for the delivery delay is 50 milliseconds in a multi server environment. The delivery delay is handled by the message queue instance itself, which introduces the need, that the message queue server is configured to provide that functionality.

It's important to note that workflows will be triggered with a minimum delay of 50 milliseconds with these settings.

Configuration