On 09.01.19 15:01, Daniel Klco wrote:
I would argue though that there is a significant loss of functionality by
eliminating the ability to see what jobs exist on an instance.
Agree, that's why I suggested B over A.
What if
rather than eliminating the functionality entirely a new interface was
created for a "LocalJobManager" and the query based functionality moved
there? This interface would only be supported for the resource-based
implementation and would allow for querying only the local instance (e.g.
it may not accurately reflect distributed jobs).
If the LocalJobManager interface becomes optional, then what is a user
of that interface to do when it is not available (eg in an alternative
event implementation)?
On another topic, what does everyone think of adding a method into the Job
interface for getting the entire ValueMap / java.util.Map of properties?
Right now it's very cumbersome to work with jobs via Expression Language.
Not sure I understand - why would Job.getProperties() not suffice?
Cheers,
Stefan
On Wed, Jan 9, 2019 at 3:05 AM Stefan Egli <[email protected]> wrote:
The problem is two fold:
(a) having to support job queries makes messaging-based implementations
hard. You typically don't want to do queries against a messaging system.
So this is not only about the default resource-based implementation but
allowing alternatives better.
(b) in order to support queries in the existing resource-based
implementation we're using indexes already. So the query itself is not
expensive - but maintaining the index is a cost which you don't need to
do if there wouldn't be any query to support in the first place.
So it's two different aspects which both would benefit if there were no
queries to support.
With variant A we'd get rid of them long term, with variant B we're
selectively getting rid of them on a case-by-case basis.
Cheers,
Stefan
On 09.01.19 01:32, Daniel Klco wrote:
Yeah I must admit I'm confused as well, looking through the email threads
the original proposal is to return and a iterator rather than a
collection.
If the problem is that too many jobs being returned causes heap issues, I
would think this would resolve that problem. Is there some other problem
here? If it is in query performance, could it possibly be solved using
oak
indexes?
On Tue, Jan 8, 2019, 3:50 PM Jason E Bailey <[email protected]
wrote:
So I'm missing something here, from what I gather so far, the methods
that
are being deprecated are to prevent a performance issue but the node
structure that represents the jobs is in one place isn't it? How in the
world are we getting a performance issue from that?
Is there a use case to demonstrate the performance problem?
--
Jason
On Tue, Jan 8, 2019, at 11:12 AM, Carsten Ziegeler wrote:
Hi,
I agree, variant B sounds like the better option due to the reasons you
mention. It also provides a step by step way of moving a single type of
jobs to not use search anymore.
The only downside is that this doesn't force anyone to think about her
job usage as everything just runs as before. Only if you want to
improve
you can and adjust the configurations.
Regards
Carsten
Stefan Egli wrote
Hi,
I've given this job query issue some more thought and would like us to
discuss and hopefully soon agree on which way we go:
Variant A: deprecate job query methods (as suggested originally):
* upside: eventually we'll have a cleaner job API
* downside: users of the job query API need to find alternatives to
queries, individually
Variant B: allow disabling job queries (https://s.apache.org/68ys):
* upside: allows performance optimizations on a case-by-case basis
(optimizations include not requiring indexing), thereby promoting
query-less use cases going forward without API deprecation
nevertheless.
* downside: we stick to the current job API
Note that in both cases the 'org.apache.sling.event.jobs' export
version
will have to be updated from 2.0.1 to 2.1.0 - which will affect
users/customers that implement interfaces from that package (that's
not
something typical though, but there are a few exotic cases where
that's
the case).
At this stage I'm in favour of variant B as I don't see a good
alternative for job queries other than users re-implementing a fair
chunk of the sling event implementation themselves (which would sort
of
defeat the purpose, besides the fact that it would not be trivial as
there aren't enough hooks in the API for anyone other than the
implementor to do this consistently).
Cheers,
Stefan
On 17.12.18 16:08, Stefan Egli wrote:
We could introduce a config option which would allow a job queue to
opt-out of job queries voluntarily. That would allow the
implementation to treat those jobs differently (cheaper, without
indexing them).
I guess such a new opt-out of queries mechanism could be less
controversial and provide at least some short-term gain. It doesn't
answer the question how job queries should be replaced though..
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
