When the reaper runs, and finds a group that is in the
process of being completed, the reaper blocks on the
lock, but when the lock is released, goes ahead and
reaps the group.
Now, after obtaining the lock, the reaper checks to
see if the modified date changed and, if so, aborts
the reap of the group this time around.
Required adding lastModified accounting for SimpleMessageGroup
(accounting already exists for other message groups).
Test case reproduced the problem, demonstrating duplicate
output messages.
After the fix, it shows the reap was aborted in the debug
log.
INT-2751 Polishing
PR Comments
913a8058dd