[
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792798#comment-13792798
]
Stefan Seifert commented on SLING-3028:
---------------------------------------
some feedback from my side. i have not used the job API until now, just started
reading the API and comparing to our needs for such an API. so perhaps i found
some points on methods already released which cannot be changed any more, in
this case we can ignore them.
# JobBuilder.ScheduleBuilder: why only for hourly, dayly, weekly? whats about
monthly, yearly? esp. because we have a good support for persisting jobs and
picking them up later on this job processing is suited for seldom running jobs
as well. like cron.
# btw., dayly is misspelled. daily is correct.
# Job.getProcessLog() - is it a good solution to use a String[] type for this?
as i see this is currently through all the implementation that every writing of
a log message reads gets the existing string array, copies it to a new array
and adds the new log message. the reason is that its easy then to store it in a
JCR compatible value map. i'm just thinking if its a good idea if a job
produces thousands of log messages. perhaps its acceptable overall. if you
think about and admin GUI which refreshes every second to show the log messages
of a job currently running... perhaps it would be nice to have a listener
interface for such log messages as well.
# the JobUtil class is deprecated by 90%. perhaps its better to deprecated it
completely and move the remaining 10% to a new location or other classes more
suitable. This would solve the inconsistency with the JobUtil.JobPriority enum
as well, which is not part of the Job interface, whereas JobType is part of the
Job interface.
# 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.
# Concerning job type (=state) we have the values QUEUED, ACTIVE, SUCCEEDED,
CANCELLED.
** how type/state is set if the job sets a state/result FAILED? SUCCEEDED or
CANCELLED? both is not correct.
** (btw. CANCELLED is british englisch, CANCELED is american english)
** in our own job implementation with have states for "transitions" as well
like "CANCELING". this is useful because sometimes a job that is canceled
cannot cancel at once, but takes some seconds or minutes to wait for the best
time when the job can be canceled. if this job is displayed in a management GUI
it would be helpful to show this transition state as well. to make it complete
a transition state "STARTING" should be added as well.
** more enhance features like PAUSING/PAUSED/RESTARTING could be added in the
feature - too much for now
# when reading the API i was a bit puzzled what is the exact meaning of the
"job name", it seems to be handled like a job id because it has to be unique,
but here is another job id generated by the queue. when reading the name "job
name" one might think that this is a "human readable name" for a management
gui. but because it has to be unique this is not the case. but i've no idea for
a better name because "id" is already used. perhaps the javadocs (and later the
website docs) should explain this a bit more. does it have to be unique only
concerning the active/scheduled processes, or does it have to be "all-time"
unique including the historical processes?
# JobBuilder.schedule - for what is the parameter "name" used? i does not get
its meaning from the javadocs. why is it required to make it unique?
# is it possible to add own queue implementations? does not seem so, its using
a hardcoded enum. in our own job implementation we have e.g. a "time window
queue" think, which queues up jobs and executes them only in defined time
windows where low user traffic is expected on the instance.
# we need a possible to store complex result structures in our jobs, e.g. a
subtree of nodes/resources with static and other process infos, definitely too
much for a single string. ok, we could build an JSON structure and pass it over
as log messages, but this would e really ugly hack. it would be possible to
store this structure in the job logic and have an own management gui which can
detect this additional result info by job id and display it. but when thinking
about a cluster of nodes where the job runs only on one node it would be good
to collect this job results centrally. i've not a perfect idea for an API
extension for this, perhaps we should create a separate ticket for it.
> Support for progress tracking of jobs and keeping jobs
> ------------------------------------------------------
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Victor Saar
> Assignee: Carsten Ziegeler
> Labels: jobs
> Fix For: Extensions Event 3.3.0
>
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track
> progress, which can be shown in a console for the user. This should include
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to
> give access to failure information/log stream
--
This message was sent by Atlassian JIRA
(v6.1#6144)
