DMC/scipro
7
0
Fork 0
Code Issues 31 Pull Requests 3 Actions Projects 1 Wiki Activity

Reset the failure flag in workers on successful runs. #76

Merged
tozh4728 merged 4 commits from fix-worker-stuck-in-failed-state into develop 2025-01-14 14:50:32 +01:00
Conversation 3 Commits 4 Files Changed 1 +16 -3
1 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
core/src/main/java/se/su/dsv/scipro/workerthreads/AbstractWorker.java
View File

@ -1,9 +1,6 @@
package se.su.dsv.scipro.workerthreads;
import jakarta.inject.Inject;
import jakarta.inject.Provider;
import jakarta.persistence.EntityManager;
import jakarta.persistence.EntityTransaction;
import java.util.Date;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@ -58,6 +55,22 @@ public abstract class AbstractWorker implements Worker {
* Do manually transaction-handled work
*/
try {
// When the switch from Guice to Spring happened all workers became singletons
// because that's the default in Spring. In Guice they were "prototype" scoped
// and therefore the worker object was re-created before each execution which
// reset the successfulWorker field to true.
//
// Now that they're singletons the field is never reset to true after a
// failure and the worker will be stuck in a failed state even after a
// subsequent successful run.
//
// TODO:
// In the future this flag should be removed and any execution that does
// not throw an exception should be considered successful.
// If a worker needs to signal a non-exception as a failure that should
// be an internal matter and not something the scheduler should consider.
setSuccessfulWorker(true);
doWork();
} catch (RuntimeException ex) {
LOGGER.info("Worker {} threw an exception", getClass().getSimpleName());