sodonnel commented on code in PR #3497:
URL: https://github.com/apache/ozone/pull/3497#discussion_r1040948594
##########
hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/container/replication/ReplicationSupervisor.java:
##########
@@ -147,6 +150,17 @@ public void run() {
final Long containerId = task.getContainerId();
try {
requestCounter.incrementAndGet();
+ if (task.getTimeoutMs() != 0) {
+ long msInQueue =
+ Duration.between(task.getQueued(), Instant.now()).toMillis();
Review Comment:
There are 2 queues in the DN, the main command queue and then the
replication queue. The time set for getQueued() is the time the command is
placed onto the replication queue. However, there are some delays in the system
here eg:
1. The command is created in SCM and queued on SCM. It could be a full DN
heartbeat interval before it gets picked up.
2. The commands lands on the DN command queue. Something may hold it up
getting onto the replication queue.
I think this would mean the pending operation in SCM could expire before DN
command does, and it gives SCM a chance to schedule another command before this
gets expired on the DN.
I think it might be better if we set the expiry time on the command (in ms
since epoch) when it is created in SCM to match the SCM timeout, and then it
avoids any of these delays. Infact, it may make sense to make the DN command
expiry a little less than the SCM timeout, so the DN command tends to expire
slightly earlier than the SCM timeout.
--
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]
