guillotinaweb/guillotina_amqp

guillotina_amqp's Issues

Define all job states

Right now we have them all scattered around the code. Would be useful, as a reference for the user, to have the list of possible states for a job and their meaning

Adding metrics

It would be nice to add custom metrics that can later be exported to prometheus.
Any ideas on how could this be done?

I guess first step would be to make guillotina_prometheus as a requirement of this plugin?

Then add a custom middleware?

Newer versions not published to pipy

Even though the tag an the release are there for version 2.0.0, it seems that the package was never uploaded to pipy

>> venv/bin/pip install guillotina_amqp==2.0.0                                                                                                    
Collecting guillotina_amqp==2.0.0
  Could not find a version that satisfies the requirement guillotina_amqp==2.0.0 (from versions: 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8)
No matching distribution found for guillotina_amqp==2.0.0

Improve request cloning

Investigate whether we need to clone the request anymore for the plugin to work, since in G6 we are using task vars to keep request state.

If so, provide a clone operation at the guillotina request class and use it here.

Result should not come in an array

Currently, responses for @amqp-info/{task_id} are:

{
  "status": "finished",
  "updated": 1550497255.526748,
  "eventlog": [
    [
      "2019-02-18 13:41:16.961",
      {
        "members_count": 3,
        "completed": false
      }
    ],
    [
      "2019-02-18 13:41:16.963",
      {
        "members_count": 3,
        "completed": true
      }
    ]
  ],
  "job_data": {},
  "result": [
    {
      "members_count": 3,
      "completed": true
    }
  ]
}

Where the actual job result comes in a list with only one dict element.
We should probably make it just an outer dictionary (without the list) right? Would make it easier to parse

Unless there is a reason to keep it as a list, of course

Handle possible clogging of aioamqp client

Sometimes aioamqp goes wonky and stops receiving. We want to restart the worker if this happens.

@dmanchon 's proposal to solve this issue was:

@lferran @vangheem i propose a beacon message in another queue/exhange (with fanout) to sense if we are receving the messages, if we dont get activity on that queue then we kill the worker, if we receive the beacon then we send it back to a delay queue, that after some time will queue it on the main-beacon queue again.
We can add that on the watchdog logic.