[HDDS-9960] OM State machine lastIndexUpdate consume memory

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Labels: pull-request-available
• Assignee: Sumit Agrawal
• Reporter: Sumit Agrawal
• Created: 19/Dec/23 05:19
• Updated: 04/Jan/24 06:33
• Resolved: 04/Jan/24 06:33

Description

update lastTransactionIndex is also done from another flow,

ratis --> notifyTermIndexUpdated(). --> computeAndUpdateLastAppliedIndex() -->  else part (for flow from ratis)

} else {
  if (getLastAppliedTermIndex().getIndex() + 1 == lastFlushedIndex) {
    updateLastAppliedTermIndex(currentTerm, lastFlushedIndex);
    if (LOG.isDebugEnabled()) {
      LOG.debug("ComputeAndUpdateLastAppliedIndex due to notifyIndex {}",
          getLastAppliedTermIndex());
    }
  } else {
    ratisTransactionMap.put(lastFlushedIndex, currentTerm); 

If lastTransactionAppliedIndex and ratis transaction index difference is only "1", it update the last transaction index. This can cause db flush transaction to be behind the ratis transaction. So replay of those tranasaction will not happen in case of OM crash at this point.

 

So there is a two different behavior exist, that when to update lastAppliedTransaction, creating confusion about expectation for this perspective.

 

Also its observed updating last applied transaction stuck when there is difference in transaction index due to exception. This was causing ratisTransactionMap holding large number of transaction and not applied. https://issues.apache.org/jira/browse/HDDS-9342.

 

Issue Links

• is duplicated by: HDDS-10026 Remove applyTransactionMap and ratisTransactionMap from OzoneManagerStateMachine
• relates to: HDDS-9342 OM restart failed due to transactionLogIndex smaller than current updateID
• links to: GitHub Pull Request #5826
• links to: GitHub Pull Request #5848