https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #2 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Hi Kyle, you embedded unrelated changes (sip). This would make sense in some cases (job types), but I think it should default to 1 to keep the existing behaviour (we don't want 10 long tasks/batch mod running at the same time). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144946|0 |1 is obsolete| | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #2)

Hi Kyle, you embedded unrelated changes (sip). This would make sense in some cases (job types), but I think it should default to 1 to keep the existing behaviour (we don't want 10 long tasks/batch mod running at the same time).

Yep, that was an accident. It just took me a few minutes to untangle ;) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #7 from David Cook <dcook@prosentient.com.au> --- An alternative would be to launch more background_jobs_worker.pl processes, although that would require updating the koha-worker script. Speaking of the koha-worker script, how would the max processes be configured for it? Perhaps something in debian/koha-common.init that can be overridden in /etc/default/koha-common? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32561 --- Comment #9 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Jonathan Druart from comment #8)

The first argument could be the memory footprint, but with bug 28413 it should not be a problem.

And just noticed that it's broken, see bug 32561. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #10 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to David Cook from comment #7)

An alternative would be to launch more background_jobs_worker.pl processes, although that would require updating the koha-worker script.

Would that work with the database polling method? I think that would require some re-engineering. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #12 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Kyle M Hall from comment #11)

(In reply to Jonathan Druart from comment #9)

...

(In reply to Jonathan Druart from comment #8)

...

The first argument could be the memory footprint, but with bug 28413 it should not be a problem.

And just noticed that it's broken, see bug 32561.

I had another thought triggered by bug 32561. Your solution on that bug only keeps the memory footprint down until the first time that the require for Koha::Plugins is evaluated. At that time the memory usage will jump back up and remain there. With this patch, those inflated processes will go away after processing that job. I think both techniques should be implemented for maximum flexibility. For example, someone may want to deploy a fast queue with 20 max processes, and a slow queue with 10 max processes.

Just remembered that the process forks, so I think my memory concern is invalid. I do think the rest of my comment stands though ;) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #13 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 145043 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145043&action=edit Bug 32558: (follow-up) Allow configuration of max processes via env or koha conf -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #15 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #14)

From https://www.grzegorowski.com/rabbitmq-406-channel-closed-precondition-failed

"You have to ACK messages in same order as they arrive to your system"

If this is correct, forking is not an option here.

I have not found something similar in rabbitmq doc however.

You are correct. I've been reading a lot about ACK messages, and we are using them wrong. ACK isn't suppose to indicate a process has completed. It's only meant to indicate the a message has been received. In fact, sending ACK messages appears to be optional. This is from the O'Reilly book Mobile and Web Messaging: --- By default, the STOMP broker will consider the message automatically acknowledged when it is delivered to the consumer. However, there are cases in which the consumer may prefer to explicitly acknowledge the message. It leaves a window of opportunity to determine whether it can handle the message or not. For example, the client needs to write the message payload in a data store. There may be issues with opening a connection to the data store and the client could choose to acknowledge the message only after having successfully written its body to the data store. In case of failure, it will instead nack the message (explicitly refuse to take ownership of it). When the STOMP broker is informed of this negative acknowledgment, it may then decide to deliver the message to another consumer subscribed to the destination or try again some time later depending on its configuration. --- I will submit a following so that we ACK the message before forking. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #17 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- This contradicts https://metacpan.org/pod/Net::Stomp#ack """ This acknowledges that you have received and processed a frame and all frames before it (if you are using client acknowledgements) """ -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #18 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #17)

This contradicts https://metacpan.org/pod/Net::Stomp#ack

""" This acknowledges that you have received and processed a frame and all frames before it (if you are using client acknowledgements) """

That interpretation contradicts the STOMP protocol specification: https://stomp.github.io/stomp-specification-1.2.html#ACK I think the problem here lay in the vagueness of the phrase "processed a frame". That doesn't mean "completed a task". It simply means the frame was successfully read by the client, and that we were able to decode the data within it, and nothing more. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #19 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Kyle M Hall from comment #18)

(In reply to Jonathan Druart from comment #17)

...

This contradicts https://metacpan.org/pod/Net::Stomp#ack

""" This acknowledges that you have received and processed a frame and all frames before it (if you are using client acknowledgements) """

That interpretation contradicts the STOMP protocol specification: https://stomp.github.io/stomp-specification-1.2.html#ACK

I think the problem here lay in the vagueness of the phrase "processed a frame". That doesn't mean "completed a task". It simply means the frame was successfully read by the client, and that we were able to decode the data within it, and nothing more.

Moving this discussion and patch to Bug 32573 to avoid scope creep. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144960|0 |1 is obsolete| | Attachment #144961|0 |1 is obsolete| | Attachment #145043|0 |1 is obsolete| | Attachment #145062|0 |1 is obsolete| | --- Comment #20 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 145067 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145067&action=edit Bug 32558: Add ability for background_jobs_worker.pl to process multiple jobs simultaneously up to a limit Right now background_jobs_worker.pl only processes jobs in serial. It would make sense to handle jobs in parallel up to a user definable limit. Test Plan: 1) Apply this patch 2) Stop background_jobs_worker.pl 3) Generate some background jobs by editing records, placing holds, etc 4) Watch processes in a new terminal: watch -n 0.1 'ps aux | grep background_jobs_worker.pl' 5) Run background_jobs_worker.pl with parameter -p 3 or some other number of max processes 6) Note the multiple forked processes in the ps output -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #22 from David Cook <dcook@prosentient.com.au> --- Was tempted to Fail QA this one, but I haven't actually tested if the current patch won't work in practice. But I think moving the forking up as I describe above would be a wise move. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #24 from David Cook <dcook@prosentient.com.au> --- What happens if you have a background_jobs_worker.pl running 4 child processes, they all ACK early, and then 1 child process crashes? That job will be stuck as "new" or "started" until the background_jobs_worker.pl is restarted and does some database polling, yes? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #25 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- The discussion on ACK early / ACK late seems to have been settled for now in bug 32573, so is it fair to conclude that we're ready to move forward with this one? If so, this patch needs to be rebased. Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 32558: Add ability for background_jobs_worker.pl to process multiple jobs simultaneously up to a limit error: sha1 information is lacking or useless (misc/background_jobs_worker.pl). error: could not build fake ancestor Patch failed at 0001 Bug 32558: Add ability for background_jobs_worker.pl to process multiple jobs simultaneously up to a limit hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-32558-Add-ability-for-backgroundjobsworkerpl-t-cxrOEt.patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #145067|0 |1 is obsolete| | --- Comment #26 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 145900 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145900&action=edit Bug 32558: Add ability for background_jobs_worker.pl to process multiple jobs simultaneously up to a limit Right now background_jobs_worker.pl only processes jobs in serial. It would make sense to handle jobs in parallel up to a user definable limit. Test Plan: 1) Apply this patch 2) Stop background_jobs_worker.pl 3) Generate some background jobs by editing records, placing holds, etc 4) Watch processes in a new terminal: watch -n 0.1 'ps aux | grep background_jobs_worker.pl' 5) Run background_jobs_worker.pl with parameter -p 3 or some other number of max processes 6) Note the multiple forked processes in the ps output -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #28 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Test notes: -Step 5 should say parameter -m 3 instead of parameter -d 3 -The above should also be documented in the help section of the script -Is the process limit still meant to be configurable via configuration files? If so, that should be added to the test plan. If it's meant to be a command-line option only, then should the <background_jobs_worker> sections of koha-conf.xml and koha-conf-site.xml.in be removed from the patch? (I don't really know much about those files yet, so hopefully that question makes sense) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #31 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Emily Lamancusa from comment #29)

*-Step 5 should say parameter -m 3 instead of parameter -p 3

Apparently I can't type it correctly either!

Thanks! I've updated the test plan in the patch! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #34 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- +Max processes will be set from the command line option, the environment variable MAX_PROCESSES, or the koha-conf file, in that order of precedence. +By default the script will only run one job at a time. I think this is not needed. Confusing too. It is already simpler if we remove the koha-conf option here. I would opt for commandline option or default 1. Setting MAX_PROCESSES or --max_processes is the same amount of work? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #38 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #34)

+Max processes will be set from the command line option, the environment variable MAX_PROCESSES, or the koha-conf file, in that order of precedence. +By default the script will only run one job at a time.

I think this is not needed. Confusing too. It is already simpler if we remove the koha-conf option here. I would opt for commandline option or default 1. Setting MAX_PROCESSES or --max_processes is the same amount of work?

default 0 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #40 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #35)

Not sure (yet) but should the default not be zero? Just do not fork like we currently do?

The job needs to run in a forked process. The memory used by the job can be reclaimed when the child process ends - whereas the memory will never be reclaimed by the OS if the process doesn't fork. (The memory can be re-used if it's internally freed within Perl but can't be reclaimed by the OS.) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #42 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #39)

(In reply to Marcel de Rooy from comment #34)

...

+Max processes will be set from the command line option, the environment variable MAX_PROCESSES, or the koha-conf file, in that order of precedence. +By default the script will only run one job at a time.

I think this is not needed. Confusing too. It is already simpler if we remove the koha-conf option here. I would opt for commandline option or default 1. Setting MAX_PROCESSES or --max_processes is the same amount of work?

If you wanted to set different options for different instances, koha-conf would be the only option that would work.

Okay. That would be an easier solution for that scenario. (We could even add a pref, haha.) If it will be really used like that, is still a question for me though. So, lets keep all options then, no blocker. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #44 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #43)

Could you remind me why we need this? Why don't you just run another worker? This area has not been very stable in the last releases and I am not sure we should play with more forking and introduce possible regressions when an alternative (run more workers) is already available.

I could be wrong but I think the premise of this change is that it would be more difficult to update koha-worker and koha-common.init to allow for a configurable number of workers than it would be to add more forks. However, I agree that it would be preferable to just run more workers. Even if it's easier to fork, I don't think this patch goes about it quite the right way... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #46 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to David Cook from comment #44)

(In reply to Jonathan Druart from comment #43)

...

Could you remind me why we need this? Why don't you just run another worker? This area has not been very stable in the last releases and I am not sure we should play with more forking and introduce possible regressions when an alternative (run more workers) is already available.

I could be wrong but I think the premise of this change is that it would be more difficult to update koha-worker and koha-common.init to allow for a configurable number of workers than it would be to add more forks.

However, I agree that it would be preferable to just run more workers. Even if it's easier to fork, I don't think this patch goes about it quite the right way...

I think these are both great ideas, and there is no reason we can't have both :) That way we can choose how many workers we have for each queue, and how many parallel processes each worker can handle. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #47 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Nothing changed, backed to FQA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #49 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- When I submit 4 stage marc imports with 3 processes (removing the extra fork in process_job), I get this: 285042 at /usr/share/koha/misc/background_jobs_worker.pl line 93. 285043 82 at /usr/share/koha/misc/background_jobs_worker.pl line 136. 285044 83 at /usr/share/koha/misc/background_jobs_worker.pl line 136. 285045 84 at /usr/share/koha/misc/background_jobs_worker.pl line 136. C4::ImportBatch::_update_batch_record_counts(): DBI Exception: DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at /usr/share/koha/C4/ImportBatch.pm line 392 C4::ImportBatch::_update_batch_record_counts(): DBI Exception: DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at /usr/share/koha/C4/ImportBatch.pm line 392 285115 85 at /usr/share/koha/misc/background_jobs_worker.pl line 136. 42 is the pid of the main process; it starts 43, 44 and 45 for three jobs. Job 82 finishes, but 83 and 84 fail concurrently on a deadlock. Job 85, the fourth import, starts later (which is fine) and finishes ok. So, this is not a problem of background worker itself, but the transaction in StageMarcForImport does not (yet) support this operation concurrently. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #51 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Opened bug 32990 to address the deadlock. Please signoff, Kyle ! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #53 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 146754 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146754&action=edit Bug 32558: (QA follow-up) Leave default to 1, remove extra fork The default of 1 resembles the old behavior: 1 fork for the job. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #146754|0 |1 is obsolete| | --- Comment #55 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 147784 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147784&action=edit Bug 32558: (QA follow-up) Leave default to 1, remove extra fork The default of 1 resembles the old behavior: 1 fork for the job. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #56 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Pushed to master for 23.05. Nice work everyone, thanks! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|32990 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32990 [Bug 32990] Possible deadlock in C4::ImportBatch::_update_batch_record_counts -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dependency -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com --- Comment #60 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Martin Renvoize from comment #57)

Should we have moved the Parallel::ForkManager dependency from 'recommends' to 'requires' in this patchset? Prior to now, it looks like it was only used in tests.

Oh, good catch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Jacob O'Mara <jacob.omara@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable Version(s)|23.05.00 |23.05.00,22.11.04 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com Version(s)|23.05.00,22.11.04 |23.05.00,22.11.04,22.05.11 released in| | Status|Pushed to stable |Pushed to oldstable --- Comment #63 from Lucas Gass <lucas@bywatersolutions.com> --- Backported to 22.05.x for upcoming 22.05.11 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558 --- Comment #65 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- use C4::Context; use Koha::Logger; use Koha::BackgroundJobs; +use C4::Context; Dup C4::Context. -- You are receiving this mail because: You are watching all bug changes.