sumitagrawl commented on PR #4939: URL: https://github.com/apache/ozone/pull/4939#issuecomment-1732971535
> Are you mean that we should consider "Does DN have too many unexecuted Block delete transactions" inside [HDDS-8882](https://issues.apache.org/jira/browse/HDDS-8882)? If the DN has too many unexecuted delete transactions, we do not send new Block delete transactions for it. > > But this is actually a similar implementation. In this PR we monitorer the length of the queue on the DN to determine whether to send a new delete transaction to the DN. This PR does not added any new queue on the SCM side. if a DN is down or other failure, its length of queue change can be monitored by SCM, so that shouldn't be a problem either. > > Based on the [HDDS-8882](https://issues.apache.org/jira/browse/HDDS-8882), it is acceptable to implement transmit control, do you have any suggestions? @xichen01 Sorry for late reply, Re-looked over this, It checks count of DN;s queue length and pending Command queue at SCM and take decision, 1. checking DN's queue length is good to avoid resending same command and being rejected by DN. 2. For commands getting queued at SMC, this check also enforce to add same command again if DN is down. nodeManager.getTotalDatanodeCommandCount(() -- returns command count at DN and at SCM together nodeManager.getCommandQueueCount() -- returns command count present at SCM only as used earlier Case: if DN command queue previoulsy is "0" or less than 5 and also DN is down, this will cause to add same command at SCM till limit "5". (duplicating exactly till 5 overall). So we can have above as additional check if required to avoid sending command if DN queue is already reached "5". May be we can check for lesser queue size at SCM to send like limit "2" to avoid duplicate for the change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
