Bugzilla – Attachment 145066 Details for
Bug 32573
background_jobs_worker.pl should ACK a message before it forks and runs the job
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
Bug 32573: Send ACK message to RabbitMQ before handling the job
Bug-32573-Send-ACK-message-to-RabbitMQ-before-hand.patch (text/plain), 2.96 KB, created by
Kyle M Hall (khall)
on 2023-01-05 16:37:41 UTC
(
hide
)
Description:
Bug 32573: Send ACK message to RabbitMQ before handling the job
Filename:
MIME Type:
Creator:
Kyle M Hall (khall)
Created:
2023-01-05 16:37:41 UTC
Size:
2.96 KB
patch
obsolete
>From ce4bf32900f295c11a7baaf887d2694628887036 Mon Sep 17 00:00:00 2001 >From: Kyle Hall <kyle@bywatersolutions.com> >Date: Thu, 5 Jan 2023 11:35:42 -0500 >Subject: [PATCH] Bug 32573: Send ACK message to RabbitMQ before handling the > job > >Splitting off this functionality from bug 32558. This is the comment that started this discussion: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558#c15 > >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. >--- > >From https://www.rabbitmq.com/stomp.html > >--- >RabbitMQ STOMP plugin supports auto, client, and client-individual subscription headers that affect how ACK on NACK operations work. > >The auto mode uses automatic acknowledgements. The client mode is manual (client-driven) acknowledgements of multiple messages at once. The client-individual is for message-by-message manual acknowledgement. >--- > >If ACK is meant to be sent post-work, why would automatic acknowledgement exist? The interpretation that an ACK is meant to be sent after handling the processing of a job doesn't make sense. > >In summary, we should be sending back ACK messages as soon as we've successfully processed ( e.g. read and decoded the data ) of a frame. Only then should we process it. > >Test Plan: >1) Apply this patch >2) Launch background_jobs_worker.pl >3) Note no changes in background job processing >--- > misc/background_jobs_worker.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/misc/background_jobs_worker.pl b/misc/background_jobs_worker.pl >index eb36f34f96..de7dc34aba 100755 >--- a/misc/background_jobs_worker.pl >+++ b/misc/background_jobs_worker.pl >@@ -96,8 +96,8 @@ while (1) { > # It could work in a first step, but then we will want to handle job that will be created from the message received > my $job = Koha::BackgroundJobs->find($args->{job_id}); > >+ $conn->ack( { frame => $frame } ); # Acknowledge the message was recieved > process_job( $job, $args ); >- $conn->ack( { frame => $frame } ); # FIXME depending on success? > > } else { > my $jobs = Koha::BackgroundJobs->search({ status => 'new', queue => \@queues }); >-- >2.30.2
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
|
Splinter Review
Attachments on
bug 32573
:
145066
|
145594
|
145595
|
145608
|
145612