[
https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794536#comment-13794536
]
Stefan Seifert commented on SLING-3169:
---------------------------------------
ok, lets have a look on the current implementation:
{code}
enum JobType {
QUEUED,
ACTIVE,
SUCCEEDED,
CANCELLED
};
public enum JobState {
SUCCEEDED, // processing finished successfully
FAILED, // processing failed, can be retried
CANCELLED // processing failed permanently
}
{code}
a new, merged enum could look like this:
{code}
enum JobState {
QUEUED, // waiting in queue after adding or for restart after failing
ACTIVE, // job is currently processed
SUCCEEDED, // processing finished successfully
CANCELLED, // processing was canceled during processing
FAILED // processing failed even after the number of configured retries
};
{code}
please note that i slightly redefined some of the states, this can be
questioned of course. first of all i think the merging is a good option, it
removes the partially redundancy betweend the two enums and solves the naming
clash problem in an elegant way. i thought it was usful for a reporting
perpective of history jobs to have a distinction whether a job was failed due
to errors, or because it was interrupted by human or other intraction via the
stopJobById method.
but the merging has one problem: the enum is used as part of the JobStatus
class to allow the job reporting back its status from the JobConsumer point of
view. then it would be possible for the consumer to report the status "QUEUED"
or "ACTIVE" - which should not be allowed. this could be handled by ignoring it
and logging an error, but still is not elegant. perhaps reducing the JobStatus
succeeded feedback to a boolean true/false? the job engine knows if it forced a
stopping/canceling of the job or not. (but to be precise it does not know if
the stop event was ignored by the job consumer and the job perhaps succeeded
anyway)
> 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)
