[Koha-bugs] [Bug 32573] New: background_jobs_worker.pl should ACK a message before it forks and runs the job

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Jan 5 17:32:37 CET 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32573

            Bug ID: 32573
           Summary: background_jobs_worker.pl should ACK a message before
                    it forks and runs the job
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Architecture, internals, and plumbing
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: kyle at bywatersolutions.com
        QA Contact: testopia at bugs.koha-community.org

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.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list