https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506
--- Comment #27 from Jonathan Druart <[email protected]> --- I actually never want to fight, ever. I appreciate everyone who has worked on this, including you Tomás. I'm writing to add some history that may be missing, and to make my point. History - In 2011 I wrote misc/solr/IndexRecordQueue.pl at BibLibre (branch biblibre/dev/solr). It was a configurable daemon (record type, maximum number of records, maximum delay, etc.). So the idea of a flexible, configurable queue is not new to me :D - Bug 15032 ("[Plack] Scripts that fork don't work") was filed in 2015. Over the following years I tried several approaches: a background_jobs table and a progress bar in 2017, a daemon watching a DB table [1][2], Minion, and in 2019 a RabbitMQ proof of concept on bug 22417. - Getting 22417 in took a while. It was "In Discussion" for about a year, the first signoff came 17 months after the POC, and it was pushed in October 2020. During that time I asked for feedback, testing or review many times, on koha-devel, IRC (private and public) and the bugs. I got input along the way, but it was very long. - The "Going further" list from 22417 included: a) rewrite the task scheduler with Koha::BackgroundJob (bug 1993) b) provide a configuration file to prioritize or postpone jobs c) server-side, there is the possibility to configure a lot of things, like users, destinations, SSL, etc. By default guest/guest has localhost access only Since the push, I have fixed the problems that came with RabbitMQ. Most of the time I was on my own, and improvements or bugfixes didn't get attention. With that in mind, you might understand my frustration. My point - I understand that most providers have turned RabbitMQ off, and I am not asking to keep supporting STOMP at all costs. - My concern is different. Bug 43729 removes the broker, but also ignore the abstraction: the worker has a single hard-coded mechanism and JobsNotificationMethod goes away. I think that is a step back from what we need. - The layering suggested on bug 35920 seems the right one, and several people said they liked it. I argued against it on that bug (comment 5), and I changed my mind. Keeping a small backend interface costs very little and keeps the door open for a task scheduler, a dispatcher, or even a broker again later. I don't understand why bug 43729 has been opened without being linked to this discussion. It's not only about removing RabbitMQ. We need to communicate about its removal, making sure everybody agreed, cleaning up bugzilla (it's full of bug reports), and discussing/advertising the next steps... We definitely need to get out of the status quo, and I'm fine with removing STOMP if nobody wants to maintain/use it. But it's sad to lose the abstraction on the way. [1] https://lists.koha-community.org/archives/list/[email protected]/thread/KS3GDBEPMZQBUGIX72GWWSK53FZC5UWT/ [2] https://gitlab.com/joubu/Koha/commits/bug_15032_other_tries -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
