Description
If you are producing and consuming batch events in a clustered environment in LiveCycle ES2 you may notice that all events produced are consumed on the same cluster node. This is the expected behaviour even though it may seem as though LiveCycle is not making use of the distribution benefits of a clustered environment.
This behaviour is related to the run-time property of the process, i.e. short-lived (synchronous) versus long-lived (asynchronous).
Explanation
| Producer process | Consumer process | Result |
| Short-lived | Long-lived | Distributed |
| Short-lived | Short-lived | Same node |
| Long-lived | Short-lived | Same node |
| Long-lived | Long-lived | Distributed |
When the consumer process is short-lived, the event is created on the 1st cluster node (server1), and a work item to handle the event is created and assigned to the workmanager on server1. The workmanager handles the work item and synchronously invokes the short-lived consumer process. The execution of that process happens in the same workmanager thread and so everything happens only on server1.
When the consumer process is long-lived, the event is created on server1, and a work item to handle the event is created and assigned to the workmanager on server1. The workmanager handles the work item and asynchronously sends a request to the JobManager to invoke the long-lived process. At this point event handling is done and everything has happened on server1. At some point after this, JobManager picks up the invocation request and starts the long-lived consumer process. This can happen on either node (server1 or server2) in the cluster.
reference: (182264457)