GitLab

import CubicWebTC before cubes.* to enable magic import of cubes

This allow to have a smooth transition to cubicweb-celerytask

Run tasks using celery instead of subprocesses, keeping API compatibility for
incremental transition to cubicweb-celerytask.

This allow installation from the python source distribution

[hooks,workutils] Create a looping task to abort "lost" workertasks which are running for an abnormally long time.

Related to PG-3206

Since CW 3.19 doesn't enforce foreign key constraint on inlined relations, test
if the task exists before adding a WorkerLogArchive on it.

This should prevent potential race condition when task is deleted while
WorkerLogArchive are added to it (this should NOT happen, but just in case...).

Avoid the need to update the test each time entities.py is modified

To migrate from the devel version (4.0.0), require a:
add_relation_definition('CWWorkerLogArchive', 'archive_of', 'CWWorkerTask')

also, simply log error on failed kill attempt instead of flawing the
transaction.

Currenly, there is no commit/rollback done util some task is processed. This may
cause very long (read-only) transaction if the process doesn't grab any task for
a while. It seems that such transaction causes tempdb to grow up indefinitly
when running with sqlserver. Rolling back systematically there should avoid
this.

Indeed there is no garantee the client will call it `ticks` times
and in this case there would be a dangling cnx (waiting to be
garbage collected, but still).

Also, we start the count at 1 to avoid the first step to set the progress at 0.

Some badly coded tasks may not release all their connections.

We want to avoid a worker being stuck in limbo: still running
but unable to effectively process tasks.

We log the tasks that steal connections.

A `mincnxfortasks` parameter is provided. It must be equal or smaller
than `availablecnxfortasks`. The point of having another config entry
is to give some affordance when production sites use known-leaking tasks
but we don't want to restart a fresh worker after each of those.

Of course the proper course of action must be, in the end, to find
and fix the leaks.

This can be a useful memory leak avoidance tool, as cubicweb
instances tend to easily leak memory.

This can happen either because we land there too early or
because by the time we are asked to compute this, the
entity has been deleted.

The string representation of a task included the state name for
convenience - this is used by the worker when it logs its stuff.

This causes troubles when the task has no state yet. In fact, when
`__str__()` asks for the state of the corresponding task, the state
property code (in cw/wfobjs) badly re-calls `__str__()` (to warn
about the missing state) which results in a nasty loop.

The default (quite low) value may be not sufficient for some tasks
that, for instance, consume new connections in post-commit events.

Also two connections are reserved for the worker machinery itself.

Just before creating the connections pool, cubicweb
reloads the whole configuration files, hence
resetting any previously modified value.

This can hurt badly when on a `deleteconf` view of many (finished) tasks.

By default workers will process the currently running task before
detecting a service shutdown and disappearing.

Some may prefer that a service shutdown be followed by an immediate
worker exit, including aborting the current task if any.

Closes #7423455.

The possible causes are:
* instance shutdown (in debug or service mode)
* task abortion
* byzantine failure

Closes #7423207.

Indeed, killing a process from its child makes windows nervous.
Additionally, we fix the import in `startprocess`.

Related to #6476594.

Since indeed it will not be maintained in case of a violent process kill.
Related to #6476594.

Related to #6476594.