Rollback
When an event is consumed from a queue transactionally, there is a chance that the transaction will be rolled back. This could be triggered by the user or by a disconnection. When this happens, the event needs to be put onto the queue for redelivery.
Note that for performance reasons for asynchronous consumers, Universal Messaging can deliver a window of messages to the client. So if the user rolls back event 0, they will receive the window of events already on the client before they consume event 0 again. It is possible to set the client window to be only 1 event, and doing so will guarantee event ordering.
The window size is set on the nQueueReaderContext for queues, and on nChannel.addSubscriber(..., windowSize) for channels. It is only relevant for asynchronous consumers.
Using a small window size affects the performance negatively, since this increases the number of windows Universal Messaging server has to deliver. Therefore, if your application does not require rolled-back events to be ordered, we suggest leaving the default windows size unaltered.
Note:
Prior to version 10.5, for queues, when rollback happens, the event is re-added to the front of the queue and is assigned a new event ID. So if an event is rolled back, that event will be added straight back at the front of the queue ready for redelivery. The API method event.getHeader().getOriginalTransactionEID() returns the event ID that the event had when it was first published to the queue; this value is only set on republish.