This is an alternative to connector workers, with the goal of resolving issues due to the polling nature of workers:
It is fully compatible with the connector mechanism and only replaces workers.
/connector/runjobHTTP request. 
ODOO_CONNECTOR_CHANNELS=root:4(or any other channels configuration)
xmlrpc_portis not set:
channels = root:4in the
[options-connector]section of the odoo configuration file.
--workersgreater than 1. 
...INFO...connector.jobrunner.runner: starting ...INFO...connector.jobrunner.runner: initializing database connections ...INFO...connector.jobrunner.runner: connector runner ready for db <dbname> ...INFO...connector.jobrunner.runner: database connections ready
enqueuedstate after the Odoo server is halted. Since the runner has no way to know if they are actually running or not, and does not know for sure if it is safe to restart the jobs, it does not attempt to restart them automatically. Such stale jobs therefore fill the running queue and prevent other jobs to start. You must therefore requeue them manually, either from the Jobs view, or by running the following SQL statement before starting Odoo:
update queue_job set state='pending' where state in ('started', 'enqueued')
|||From a security standpoint, it is safe to have an anonymous HTTP request because this request only accepts to run jobs that are enqueued.|
|||It works with the threaded Odoo server too, although this way of running Odoo is obviously not for production purposes.|
Channel(name, parent, capacity=None, sequential=False)¶
A channel for jobs, with a maximum capacity.
When jobs are created by connector modules, they may be associated to a job channel. Jobs with no channel are inserted into the root channel.
Job channels are joined in a hierarchy down to the root channel. When a job channel has available capacity, jobs are dequeued, marked as running in the channel and are inserted into the queue of the parent channel where they wait for available capacity and so on.
Job channels can be visualized as water channels with a given flow limit (= capacity). Channels are joined together in a downstream channel and the flow limit of the downstream channel limits upstream channels.:
---------------------+ | | Ch. A C:4,Q:12,R:4 +----------------------- ---------------------+ Ch. root C:5,Q:0,R:4 | ---------------------+ Ch. B C:1,Q:0,R:0 ---------------------+-----------------------
The above diagram illustrates two channels joining in the root channel. The root channel has a capacity of 5, and 4 running jobs coming from Channel A. Channel A has a capacity of 4, all in use (passed down to the root channel), and 12 jobs enqueued. Channel B has a capacity of 1, none in use. This means that whenever a new job comes in channel B, there will be available room for it to run in the root channel.
Note that from the point of view of a channel, ‘running’ means enqueued in the downstream channel. Only jobs marked running in the root channel are actually sent to Odoo for execution.
Should a downstream channel have less capacity than its upstream channels, jobs going downstream will be enqueued in the downstream channel, and compete normally according to their properties (priority, etc).
Using this technique, it is possible to enforce sequence in a channel with a capacity of 1. It is also possible to dedicate a channel with a limited capacity for application-autocreated subchannels without risking to overflow the system.
ODOO_CONNECTOR_CHANNELS environment variable must be
set before starting Odoo in order to enable the job runner
and configure the capacity of the channels.
Alternatively, set the channel configuration in the Odoo configuration file:
[options-connector] channels = root:4
If the channel configuration is present in both the environment variable and the configuration file, the environment variable takes precedence.
The general syntax is
Intermediate subchannels which are not configured explicitly are autocreated with an unlimited capacity (except the root channel which if not configured gets a default capacity of 1).
Example values for
root:4: allow up to 4 concurrent jobs in the root channel.
root:4,root.sub:2: allow up to 4 concurrent jobs in the root channel and up to 2 concurrent jobs in the channel named
sub:2: the same.
It’s also possible to separate channel entries with line breaks, which is more readable in the configuration file:
[options-connector] channels = root:4 sub:2