Ngone51 commented on a change in pull request #24848: [SPARK-28014][core] All
waiting apps will be changed to the wrong state of Running after master changed.
URL: https://github.com/apache/spark/pull/24848#discussion_r294891919
##########
File path: core/src/main/scala/org/apache/spark/deploy/master/Master.scala
##########
@@ -561,7 +561,7 @@ private[deploy] class Master(
apps.filter(_.state == ApplicationState.UNKNOWN).foreach(finishApplication)
// Update the state of recovered apps to RUNNING
- apps.filter(_.state == ApplicationState.WAITING).foreach(_.state =
ApplicationState.RUNNING)
+ apps.filter(_.coresGranted > 0).foreach(_.state = ApplicationState.RUNNING)
Review comment:
Hmmm...with the current code logic, I'd say yes that an app could always
update to RUNNING from WAITING whenever it gains an executor. Then, the WAITING
status, here, exactly means that **the app is waiting for at least one
executor**. As a result, an app in Standalone with dynamic allocation could
change its status from RUNNING/WAITING to WAITING/RUNNING back and forth. But,
usually, it doesn't make sense.
The argument here, I think, is that how do you define the WAITING status for
an app in Standalone. If you say, an app should be in WAITING if it does not
own any executors at the moment. Then, current code logic and PR change would
be fine. But, if you say, an app should be in WAITING if it hasn't launched its
driver. Then, current code logic may be wrong.
----------------------------------------------------------------
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:
us...@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
