Because I was looking at the Sling 7 JavaDoc :-) Strangely the Job interface doesn't seem to be present in the newer JavaDocs.
On Wed, Jan 9, 2019 at 10:31 AM Stefan Egli <[email protected]> wrote: > 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] > >>>>> > >>>> > >>> > >> > > >
