search

oroinc / platform

Main OroPlatform package with core functionality.
Other
628 stars 351 forks source link

Upgrade JmsJobQueue bundle to support multiple job daemons #554

Open ishakuta opened 7 years ago

ishakuta commented 7 years ago

JmsJobQueue bundle starting from 1.3 version introduced 'lock' feature to obtain kind of lock on command in queue and guarantee that only one job daemon will process it, that allows to have multiple job daemons on different nodes without any potential issues as I understand.

1.4 version seems like minor update and should be used as target version, imho, if you'll decide upgrade is feasible.

Another idea I'd like to discuss: could it be useful to introduce sort of a 'lock' mechanism (flag in db that command is running) in Oro\Bundle\CronBundle\Command\CronCommand to avoid potential issues with simultaneous run on different nodes, in case of interference?

On a side note: new version introduced some sort of oro:cron command analog, I understand that it doesn't make sense to rewrite all existing oro:cron commands just to switch to JMS\JobQueueBundle\Console\CronCommand from Oro\Bundle\CronBundle\Command\CronCommandInterface, but maybe that's something that should be considered for future, what do you think?

P.S.: just mark it as "open for contribution" if you think it makes sense :)

hurricane-voronin commented 7 years ago

Hi @ishakuta , We are going to replace JmsJobQueue bundle with MessageQueue

artml commented 7 years ago

What Denis said. Although JmsJobQueue will remain in the LTS 1.10 branch, we won't put any resources into its enhancements and will focus on MessageQueue in 2.0 instead.

Any contributions are welcome though :)

stephanvierkant commented 7 years ago

@artml Can you share your thoughts about JmsJobQueueBundle? Why 'reinvent the wheel' and not try to improve the bundle?

DimaSoroka commented 7 years ago

@stephanvierkant , JMSJobQueue is designed to schedule Symfony console commands execution and has few big issues:

In terms if "reinvent the wheel" this is very good question, why do we need to reinvent message queue broker if there are already many of them? So based on JMSJobQueue limitation and availability of well designed and production ready message brokers we decided to integrate with one of them (RabbitMQ) instead of creating a new one. In order to simplify setup and have better adoption we also decided to invent into simplified version of message broker which is using doctrine DBAL.