[
https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796522#comment-13796522
]
Carsten Ziegeler commented on SLING-3169:
-----------------------------------------
Thanks for the feedback [[email protected]]
I've now committed a slightly different solution:
ResultBuilder result();
public interface ResultBuilder {
ResultBuilder message(final String message);
JobExecutionResult succeeded();
JobExecutionResult failed();
JobExecutionResult failed(final long retryDelayInMs);
JobExecutionResult cancelled();
}
CANCELLED vs FAILED: a job consumer result is based on what the job consumer
knows: it knows whether retrying the job does not make sense at all (CANCELLED)
or whether the job could be retried (FAILED) (the names are maybe not perfect
but that's what we picked :) ). When FAILED is signaled by the consumer, the
job engine decides based on the queue configuration (number of retries) whether
the job will be requeued or is marked as permanently FAILED. So a FAILED
returned by the consumer either results in QUEUED or CANCELLED.
And based on SUCCESS, FAILED and CANCELLED we have the notification events
right now.
Now for the enum JobState this is right now for consumers interested in the job
state, we have right now:
enum JobType {
QUEUED,
ACTIVE,
SUCCEEDED,
CANCELLED
};
where SUCCEEDED and CANCELLED are final states and QUEUED, ACTIVE the states
during queuing and processing.
The FAILED state can be detected, if the job is QUEUED or ACTIVE and the retry
count is greather than 0 - but right now we can't detect why a job is in the
CANCELLED state
So right now we don't distinguish between whether a job has been stopped by the
user, was cancelled by the consumer, throw an exception etc.
> Naming of Job related enumerations
> ----------------------------------
>
> Key: SLING-3169
> URL: https://issues.apache.org/jira/browse/SLING-3169
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: Extensions Event 3.3.0
>
>
> This is a follow up from SLING-3028 based on comments by Stefan Seifert:
> I find the enum name Job.JobType not ideal, because it does not stand of
> a type but for a state of the job. But there is a JobState enum in the
> consumer API package already.
> I find the enum and class names JobState and JobStatus in the consumer
> package not ideal, because they do not stand for a state, but for a job
> result.
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
