I would argue though that there is a significant loss of functionality by eliminating the ability to see what jobs exist on an instance. 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).
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. 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] > >>> > >> > > >
