[
https://issues.apache.org/jira/browse/HDDS-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated HDDS-5119:
------------------------------------
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, *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.
was:
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, *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 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.
> Recon file count by size page has incorrect data when keys are deleted.
> -----------------------------------------------------------------------
>
> Key: HDDS-5119
> URL: https://issues.apache.org/jira/browse/HDDS-5119
> Project: Apache Ozone
> Issue Type: Bug
> Components: Ozone Recon
> Affects Versions: 1.1.0
> Reporter: Aravindan Vijayan
> Assignee: Zita Dombi
> Priority: Major
>
> 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, *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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
