https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27783
--- Comment #31 from Tomás Cohen Arazi <[email protected]> --- (In reply to Jonathan Druart from comment #30) > 1. Shouldn't we force the job to define its queue? Otherwise I have the > feeling that we will end up with "default" everywhere. I think this can be caught at QA time. See 4. > 2. What could be other queues? Chatter on this and bug 27344 pointed to devs wantings some flexibility to run their own queues. That's why I reorganized things, keeping that in mind. Maybe later someone adds a configuration page/file to point specific tasks to specific queues, in order to offload some tasks to a separate physical server. > 3. Is BatchCancelHold really a long task? How do you define a short/long > task then? I think that was a mistake I made. i.e. cancelling holds shouldn't wait for a long running batch import to finish. > 4. Do we really want long/short task distinction? If you index 1000 records > (using batch update), it will be considered as "default" (/not long task), > but it will take a while. We do want that. And maybe in the future we can add more queues... and priorities. I think a follow-up is needed in bug 27344 to make it resort to long_tasks if the record count is high (for example, because of a batch operation) and be real-time if we are just updating an item index because it's been checked-in. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
