IF a process message queue takes too long and happens to hit the next scheduled run, messages will be duplicated and eventually sent twice. It would be nice to prevent that without changing the cron definition. Liz (PS I am aware of the existence of 15529, Tomas asked me to file this new bug as he has a different idea and didn't want to wade into all of the existing drama around the solution on 15529)
*** Bug 15529 has been marked as a duplicate of this bug. ***
Created attachment 139045 [details] [review] Bug 31342: Add execution locking to process_message_queue.pl This patch makes the script use an execution lock as provided by Koha::Script. Previous attempt got too complex and contentious, and given we have a simple way to achieve the same thing, I decided to submit an alternative approach. To test: 1. Apply this patch 2. Add the following content to misc/cronjobs/process_message_queue.pl on line 83: sleep 100; 3. Save the file 4. Have two terminals open 5. On the first one, run: $ kshell k$ misc/cronjobs/process_message_queue.pl 6. On the second one, run the same => SUCCESS: The second one dies telling it had to skip the run 7. Undo your changes: $ git checkout misc/cronjobs/process_message_queue.pl 8. Sign off :-D Sponsored-by: ByWater Solutions
Created attachment 139057 [details] [review] Bug 31342: Add execution locking to process_message_queue.pl This patch makes the script use an execution lock as provided by Koha::Script. Previous attempt got too complex and contentious, and given we have a simple way to achieve the same thing, I decided to submit an alternative approach. To test: 1. Apply this patch 2. Add the following content to misc/cronjobs/process_message_queue.pl on line 83: sleep 100; 3. Save the file 4. Have two terminals open 5. On the first one, run: $ kshell k$ misc/cronjobs/process_message_queue.pl 6. On the second one, run the same => SUCCESS: The second one dies telling it had to skip the run 7. Undo your changes: $ git checkout misc/cronjobs/process_message_queue.pl 8. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Liz Rea <liz@bywatersolutions.com>
I do not really mind about pushing this dev. But I wonder if we really address the problem here. Could we do something with status in msg queue itself? What now might happen, is not getting a lock for some reason resulting in no mails from the system at all. This sounds worse than receiving two mails to me.
As someone who has experienced both conditions, from the point of view of libraries I've had experience with, they'd rather get no mails than two. Double mails says to library patrons "the library doesn't know what they are doing and their system sucks" - no mail says "the internet is glitchy," which is true.
More succinctly: double mail is a PR problem, no mail is less so.
Created attachment 140733 [details] [review] Bug 31342: Add execution locking to process_message_queue.pl This patch makes the script use an execution lock as provided by Koha::Script. Previous attempt got too complex and contentious, and given we have a simple way to achieve the same thing, I decided to submit an alternative approach. To test: 1. Apply this patch 2. Add the following content to misc/cronjobs/process_message_queue.pl on line 83: sleep 100; 3. Save the file 4. Have two terminals open 5. On the first one, run: $ kshell k$ misc/cronjobs/process_message_queue.pl 6. On the second one, run the same => SUCCESS: The second one dies telling it had to skip the run 7. Undo your changes: $ git checkout misc/cronjobs/process_message_queue.pl 8. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Liz Rea <liz@bywatersolutions.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Pushed to master for 22.11. Nice work everyone, thanks!
I don't see this as an enhancement so I am backporting it to 22.05.x for the upcoming 22.05.07 release
applied to 21.11 for 21.11.14
Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed. Nothing to document it seems, marking resolved.