Github user squito commented on a diff in the pull request:
https://github.com/apache/spark/pull/6935#discussion_r46702279
--- Diff:
core/src/main/scala/org/apache/spark/deploy/history/FsHistoryProvider.scala ---
@@ -699,12 +853,24 @@ private class FsApplicationAttemptInfo(
endTime: Long,
lastUpdated: Long,
sparkUser: String,
- completed: Boolean = true)
- extends ApplicationAttemptInfo(
- attemptId, startTime, endTime, lastUpdated, sparkUser, completed)
+ completed: Boolean = true,
+ val fileSize: Long = -1,
+ val instance: Long = -1)
--- End diff --
Setting aside the brittleness of modtime for a moment -- what I'm saying
is, I don't see how `instance` is actually getting used to ever do anything
above and beyond modtime in the current code. in `FsHistoryProvider.getAppUI`,
you use `instance` twice. first you do `Math.max(attempt.instance,
status.getModificationTime)`, which I assume will always return
`status.getModificationTime`, and second you return `instance` directly, which
eventually makes it into `CacheEntry.data` in
`ApplicationCache.loadApplicationEntry`. But `CacheEntry.data` is ignored --
`operations.isUpdated` only looks at `entry.loadTime`. Even if
`status.getModificationTime` returns 0, so `Math.max(attempt.instance,
status.getModificationTime)` returns the instance -- I still don't see how this
fixes anything, you are just assigning some unique id for that application /
attempt. Then you're still not going to evict the cache entry until
`status.getModificationTime` eventually updates.
I'm also still not clear on the problem w/ modtime you're trying to fix.
Does it not update on a flush? Can it move backwards? Neither of those
problems seem like they'd be fixed by this. I dunno if understanding the root
of the problem better, or a better understanding of the code here, or just a
pointer to a test case would help me out here.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
