[Koha-bugs] [Bug 35092] [OMNIBUS] Remaining background job/worker issues

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #10 from David Cook <dcook at prosentient.com.au> ---
(In reply to Marcel de Rooy from comment #7)
> We should decide imo how to resolve sync issues as mentioned before. I
> thought of a few options.
> 
> [1] Still hybrid but dynamical approach. The worker should regularly check
> both MQ and DB to select new jobs. So more dynamical than the current
> approach that is determined by MQ being active or not at the start of the
> worker.
> 
> [2] Stricter distinction between MQ and DB: Add a preference like
> UseMessageQ to indicate that the worker only reads jobs from either MQ or
> DB. If you choose the DB side, the MQ will no longer be filled. If you
> choose MQ, the worker should not be able to switch to "DB mode" anymore like
> it does now.
> 
> [3] Remove DB mode: This involves "trusting MQ to be stable enough". We will
> get new jobs from MQ, and only save processed jobs in DB.
> 
> [4] Remove MQ mode: The other way around. "We do not really trust MQ."
> Remove enqueuing to MQ and reading new jobs from it.
> 
> Please give some feedback. What is the best way to go forward?

I think option 2 is a reasonable compromise. 

Personally, my preference is for the MQ. It's a great tool I use for a variety
of systems beyond Koha. I understand it well enough that I can investigate and
resolve problems encountered while using it. I think the more we use it the
more we'll learn and the better we'll become with it, and the further into the
present/future we'll move as service providers and technologists. I think it's
well known that technology moves quickly and you have to continually learn and
adapt with its progress. (Another example is using Vue.js. It's an exciting
client side technology that we'd all do well to learn both for the benefit of
Koha and ourselves as software professionals.)

That said, I can understand that some people are more comfortable using the
software tools that they already know and don't want to push boundaries or
explore frontiers. There is certainly merit to sticking to battle tested tools
that are well understood by a broad base. 

One of the downsides of option 2 is that it splits focus though. The Koha
community has limited resources and part of our success has come from most of
us implementing Koha in the same way, as we've been able to work together to
advance the project. If we continue to split between MQ and DB, we might find
it becomes more difficult to maintain.

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