Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.1.0
Description
When Recon receives a set of events as a byte[] from OM, it converts the byte[] into a list of OMDBUpdateEvents that are more useful to understand the nature of the event. These events are passed down to the list of listener tasks (FileCountBySize, ContainerKeyMapper etc) which act according to the event. The class that does this is the OMDBUpdatesHandler, and the events are iterated upon before the actual Recon's OM copy DB is updated with these set of events.
To help these tasks, the utility also tracks the 'old' value (also can be called current value) of the changed entry along with the new value that the entry is meant to be changed to. For example, during a key overwrite operation, the OMDBUpdateEvent captures the new OMKeyInfo as well the old OMKeyInfo before this update. This is useful for counter like tasks to subtract & then add appropriately. However, there is a subtle bug here. For 2 or more events that operate on the same entry (say /vol1/bucket1/key1), the old value of an event is the new value of the last event that was supposed to mutate this entry. The utility, however always thinks that the DB is always the source of the truth for the old value for the current event. This needs to be corrected.
For every event, the current (or in other words, old) value of the entry could be the last event in the current batch that changed it, or the DB if this batch did not have another event for that entry.
Attachments
Issue Links
- links to