Hi Tim, > > > I think the limit can be implemented in the loop that gets the items out of > the iterator (in the code consuming the iterator). > Since the down providers also provide iterators (and it seems they > implement those iterators properly without loading the whole content in > memory at any point), everything's in place to allow supporting a memory > efficient limit mechanism.
True. > > In order to have an API which allows this >> I suggest a query API to be added to the resource provider. If we would >> have this, we wouldn't need a new method - given that the limit is set >> to a sensible value. >> > > Do you mean that the current consumers of JobManager#findJobs would > use o.a.s.s.r.p.QueryLanguageProvider#findResources > instead ? > This would work, already now IIUC, but it would require the current > consumers of JobManager#findJobs to know about the JobManager > implementation (content structure). > I actually meant an API which doesn't exist atm - but let's forget about that idea :) > > I understand the issue with giving the ability to search for jobs in an > unbounded queues. > This streaming idea was an attempt to mitigate one of those issues (memory > consumption). > > If the plan is to soon deprecate the method completely, there's no need for > a streaming version. I think we should do this - together with a set of other methods. > > However I don't see a direct alternative to this method except using the > more generic QueryLanguageProvider#findResources which would require the > consumer to know about the JobManager internals. Or would we deprecate > without alternative (which I think makes sense from Sling PoV) ? > Yes, the idea would be to deprecate without an alternative. So there is no way to find out the contents of a queue. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
