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] > > >
