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

--- Comment #26 from David Cook <[email protected]> ---
(In reply to Tomás Cohen Arazi (tcohen) from comment #24)
> Please open your mind and take a look at how the code looks when we factor
> out STOMP, frames and its messaging edge cases.
> 
> This code is not 100% functional because the current background job classes
> are still obfuscated with frame-decoding compatibility (i.e. ->process
> expects to be passed the decoded contents from its own .data attribute) but
> this further adds to the argument about getting rid of Rabbit.

(In reply to Kyle M Hall (khall) from comment #25)
> I have to agree with Tomas. My personal experience is that Rabbit has caused
> more issues than it has solved. It has been error prone, is complicated and
> complicates Koha's code more than necessary. I think it's more than what
> Koha needs and going back to a just a polling daemon would improve Koha's
> reliability greatly for background job handling.

My personal experience has been that RabbitMQ has worked really well - both in
Koha and in multiple other projects. There have been a couple of issues over
time, but nothing that wasn't easy to fix. RabbitMQ gives us possibilities for
a future where a polling daemon won't be enough. Many systems these days
implement message brokers like RabbitMQ or ActiveMQ without issue. To me, the
biggest obstacle has been people not willing to update their skills and
knowledge, which admittedly does make it more difficult to move forward with
RabbitMQ. It feels like we are being asked to settle for the lowest common
denominator rather than the best tool for the job. 

That said, regardless of what I personally think about it, it seems that we
have 2 different groups which are unlikely to change their minds.

How about a config in koha-conf.xml or /etc/default/koha-common that lets you
decide between DB polling or RabbitMQ? 

my $worker = Koha::Worker->new({ broker => $broker });
$worker->run( { max_processes => $max_processes, queues => \@queues } );

Jonathan and I could do Koha::Worker::RabbitMQ and other folks could do
Koha::Worker::DB. 

They both need to be able to use the same incoming job JSON and store the same
result JSON. Other than that... it shouldn't matter.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to