On 4 September 2013 10:30, Carsten Ziegeler <[email protected]> wrote: > Yes, I see your point - and partially agree :) However, the notion of a > queue is slightly misleading here - in fact, the real queue is the content > stored at a specific location in the resource tree - the location includes > the sling instance id, the job topic. > The java queue implementation is "just" the execution queue on a single > instance - so for example if we would provide an implementation executing > jobs via JMS, this wouldn't be a new queue implementation, but would > require a different distribution mechanism. > In fact, I plan to get away with the queue implementations completely and > just have the queues in the resource tree with a simple implementation just > picking the "next" job resource from the resource tree and executing it.
If the content protocol for picking a job and executing it could be a public "api" then anyone wanting to do something odd could find the next job of interest, pick it and execute it. When you get to implementing the standard mechanism, if you could bear that in mind it would be good. Hopefully considering that wont make things more complicated than they need to be. Ian > > Carsten > > > 2013/9/4 Ian Boston <[email protected]> > >> Hi, >> Thanks for taking the time to explain the approach/work arround, I'll >> give it a go. >> I still think that it would be better to provide some mechanism to add >> a queue behaviour without requiring the bundle to be re-released, as I >> don't think we can predict every downstream use case in advance. >> However I don't have a concrete requirement at this stage. >> Best Regards >> Ian >> >> On 4 September 2013 08:53, Carsten Ziegeler <[email protected]> wrote: >> > Yeah, maybe - in fact it's a whitelist and a blacklist or >> > inclusion/exclusion list :) >> > In any case, we released the module already - so the name will stick :) >> > >> > Carsten >> > >> > >> > 2013/9/4 Bertrand Delacretaz <[email protected]> >> > >> >> On Tue, Sep 3, 2013 at 7:43 PM, Carsten Ziegeler <[email protected]> >> >> wrote: >> >> > ...actually black listing is exactly for these use cases. It gives you >> >> > control which instance is able to handle what jobs. So you can >> exclude a >> >> > specific instance from processing a specific job, in your use case you >> >> > exclude all but one. >> >> > This is not blacklisting of event handlers if you're refering to that >> >> one... >> >> >> >> So maybe blacklisting is not the right term in the context of jobs? >> >> >> >> IIUC this setting just causes some jobs to be ignored on some nodes, >> >> so it could be just "ignored" instead of "blacklisted". >> >> >> >> -Bertrand >> >> >> > >> > >> > >> > -- >> > Carsten Ziegeler >> > [email protected] >> > > > > -- > Carsten Ziegeler > [email protected]
