narendly commented on a change in pull request #1142:
URL: https://github.com/apache/helix/pull/1142#discussion_r453339180
##########
File path:
helix-core/src/test/java/org/apache/helix/integration/task/TestDeleteJobFromJobQueue.java
##########
@@ -44,10 +44,10 @@ public void testForceDeleteJobFromJobQueue() throws
InterruptedException {
// Create two jobs: job1 will complete fast, and job2 will be stuck in
progress (taking a long
// time to finish). The idea is to force-delete a stuck job (job2).
JobConfig.Builder jobBuilder =
JobConfig.Builder.fromMap(WorkflowGenerator.DEFAULT_JOB_CONFIG)
- .setMaxAttemptsPerTask(1).setWorkflow(jobQueueName)
+ .setWorkflow(jobQueueName)
Review comment:
Could you explain further why this change is needed? If we add more
nodes, the db partitions will get shifted. Are we adding nodes while the
workflow is in progress and before its tasks complete? In that case, the
shuffling of tasks (getting dropped and rescheduled onto another instance)
makes sense and we should increment # of attempts.
Since the focus of this test doesn't seem to be # of attempts, do you think
we should add a new test that tests for this? We want to make sure that for
targeted tasks, if we add more nodes and if that causes db partitions to be
moved, then we should observe the tasks get dropped and retried with an
increase in the # of attempts. One thing to watch out for here is
"rebalanceRunningTask" - what role should that parameter play?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
