Hi,
we already have a job API 2.0 (in commons I think) - but that's another
proprietary API which knowone outside of this circle knows about.
Deprecating means reducing complexity and making eventually the
implementation easier while at the same time having at least some form
of compatibility.
Eventually we should move to some ootb solution for job processing and
not reinvent the wheel another time. (We should have never started with
our own job processing API, but that went out of the window already). So
deprecation is a path to that other thing.
Carsten
Am 29.10.2018 um 16:53 schrieb Robert Munteanu:
Hi Stefan,
On Mon, 2018-10-29 at 14:47 +0100, Stefan Egli wrote:
Hi,
I'd like to reactivate SLING-5884 and a related discussion [1] we
had
about deprecating the query part of the Sling Event API.
TL;DR: Open question is exactly which of the JobManager methods do
we
want to deprecate.
How about depreacting the JobManager completely and creating new API
which does exactly what we want?
We can switch the JobManagerImpl to being a component registered only
if a certain configuration property is set. We can set the default to
'false' and log a WARN when we register that component to make it clear
that it's not going to be supported. Eventually we can stop registering
the implementation outright and make the inconvenient methods throw an
UnsupportedOperationException. But I would prefer to create a new API
for new 'realities'.
I know the transition will be more inconvenient, but a new API will
also force clients to make conscious choices about what they want to
support and a clear transition path.
While not giving it a lot of thought to the names and the API methods
we could support, here's a strawman API we can bash:
----------------
// do we need both submit and create?
interface JobManager2 {
SubmittedJob submitJob(...)
JobBuilder createJob(...)
}
// do we need both stop and remove?
interface SubmittedJob {
void retryJob()
void removeJob()
void stopJob()
}
interface JobStatisticsManager {
getQueue(...);
getQueues();
getStatistics();
// etc, etc
}
----------------
The separation of concerns makes it quite clear what is possible and
what not, and additionally the client is required to hold on to the
SubmittedJob if they want to do anything more with it.
We also might want to use exceptions instead of returning null in the
API, might make things clearer.
Thoughts?
Robert
The idea is to deprecate (and sometime in the future - timing tbd -
remove) those methods of the sling event api which we either
consider
expensive to support (eg maintaining large indexes for queries) or
making assumptions/limitations on the underlying implementations and
thus prohibit usable alternative implementations such as messaging-
based
ones.
Now to the discussion as to what exactly we want to deprecate and how
we
see alternatives (or not) for each (all methods of JobManager [2]):
(A) addJob, createJob: Those must stay
(B) getQueue(s), get(Topic)Statistics: Those can probably stay
(C) getJob, findJobs (and QueueType): those are the main query
methods
that should be deprecated. We'd not provide an alternative, but
could
suggest those who want to maintain job information could do that
themselves in a shared place.
(D) getJobById, retryJobById: both assume some kind of job storage
that
can be accesses in an arbitrary way. Thus I'd argue both could be
deprecated. Alternative suggestion similar to (C). Edge-case.
(E) removeJobById: can imv stay. the api makes no hard requirement
to
check if the job ever existed, however it requires that the job be
removed when returning true, so requires (expensive) synchronicity.
Doable. Edge-case.
(F) stopJobById: can imv stay.
(F) getScheduledJobs: while this requires some form of job storage
it
only affects a small amount of data. But if we'd want to make the
job
api messaging-ready it would also have to be deprecated. Edge-case.
Cheers,
Stefan
--
[0] - https://issues.apache.org/jira/browse/SLING-5884
[1] - http://sling.markmail.org/message/k3hjqcvnnabsb47j
[2] -
https://github.com/apache/sling-org-apache-sling-event-api/blob/master/src/main/java/org/apache/sling/event/jobs/JobManager.java
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
