Description
Gary Russell opened INT-2751 and commented
While a message group is in the process of being release normally, it is possible for the reaper to fire and find the same messages. Given that the group is locked (for normal processing), the reaper blocks waiting for the group. After the normal release completes, the messages are removed, and the lock released.
The reaper then continues, but fails to verify that the messages still exist in the group; hence the group is released a second time.
With some databases, Isolation.SERIALIZABLE may avoid the problem, but may cause other deadlocks depending on how the database is being used.
One possible solution will be to acquire the group lock in getMessageGroup() which is called by the reaper via the group store's iterator.
This will cause the reaper to block before doing the query, and the messages will never have existed as far as the reaper is concerned.
Affects: 2.1.3, 2.2 M4
Issue Links:
- Store the Plain Text Group Id instead or in addition to a UUID [INT-2675] #6650 Store the Plain Text Group Id instead or in addition to a UUID