Fix some problems with restoring#2141
Conversation
gianm
commented
Dec 22, 2015
gianm
commented
- TaskLockbox should consider active tasks active even if they have no locks.
- Shedding locks at startup is bad, we actually want to keep them. Stop doing that.
- stopGracefully now interrupts the run thread if had started running finishJob. This avoids waiting for handoff unnecessarily.
|
👍 |
There was a problem hiding this comment.
should we check if we were asked to stop before firing an alert while handling exception ?
There was a problem hiding this comment.
hmm, maybe only ignore it if we get an InterruptedException? other exceptions are probably worth reporting.
There was a problem hiding this comment.
wondering if its better to not release locks only if task is restorable ?
will it be better to always release old locks if there are any in case the task is not restorable (just to be on safer side)?
There was a problem hiding this comment.
I don't think there is a reason to release locks here since,
- we won't have any when we first start up (since a while ago, tasks don't get retried if they fail)
- after a second startup (restore) we really do want to keep the locks as dropping them will confuse us
gianm
force-pushed
the
fix-restoring-realtime
branch
from
8e6827e to
02f85fb
Compare
|
@gianm this has conflicts now |
- Shedding locks at startup is bad, we actually want to keep them. Stop doing that. - stopGracefully now interrupts the run thread if had started running finishJob. This avoids waiting for handoff unnecessarily.
gianm
force-pushed
the
fix-restoring-realtime
branch
from
02f85fb to
32edd15
Compare
|
@fjy fixed |
There was a problem hiding this comment.
what happened to the log line?
There was a problem hiding this comment.
It split in two and moved into the conditional below.
|
👍 |
Fix some problems with restoring
3 participants
