Limits (time!) are enforced in debugging (dev mode)

[blaggacao]

Impacted versions:
v12

Steps to reproduce:

• start server with --dev wdb,reload,qweb,werkzeug,xml
• Set a traceback
• wait enough time

Current behavior:

• Will shut down (in the middle of an open debugging session)

Expected behavior:

• Let's you debug in tranquility

odoo.service.server: Thread <Thread(odoo.service.http.request.140632278423296, started 140632278423296)> virtual real time limit (291/240s) reached.

/cc @beledouxdenis for dcb56412d667

[beledouxdenis]

You can set --limit-time-real=0,
and set it in your ~/.odoorc so you do not have to put it manually ever on your computer.
(You can save the configuration automatically using -s, e.g. --limit-time-real=0 -s

[blaggacao]

@beledouxdenis Thanks! Is this a proper fix? I tend to yes. Does the same work for limit_memory_soft and limit_memory_hard as a debugging session seems to bust default memory limits?

Could you confirm quickly and close, if you wish?

[beledouxdenis]

We consider to change the default values of the limits (time & memory) to none (0) when any of the dev tools (--dev) is set, but then we would like to apply it for the multi-workers as well, not only for the multi-threads server mode.

There is no reason to not apply time and memory limits in multi-threads in debug mode, but apply them in multi-workers. Sometimes, what you need to debug is the multi-workers mode.

Nevertheless, this is risky to apply this new limits policy according to the dev tools enabled in a stable release: Maybe somewhere in the world, a production server runs with a dev tool enabled, and no longer applying the limits in such a case suddenly may not be acceptable for the users.

If this is user-critical (or should I say developer-critical), we might do this change in stable, but at first sight we would like to change this new behavior only for the next stable release.

[blaggacao]

but then we would like to apply it for the multi-workers as well, not only for the multi-threads server mode

Nice! And thanks for the detailed explanation. So I silently assume this issue can be left open for reference.

[davidtranhp]

I would like to keep 120 for --limit-time-real in the conf. but I in some long running methods (only those methods), I would force to remove limit.

Is there a way to control the time limit at runtime?

[dreispt]

Can we have these settings set to zero when running with zero workers, as we did on previous Odoo versions? No one runs should run zero workers on Production.

[Yenthe666]

Can we have these settings set to zero when running with zero workers, as we did on previous Odoo versions? No one runs zero workers on Production.

Oh yes they do, I've seen dozens of instances without workers in production in the past. ;)

[dreispt]

Edited 😉

[beledouxdenis]

Can we have these settings set to zero when running with zero workers, as we did on previous Odoo versions? No one runs should run zero workers on Production.

Actually we do use zero workers on production, on Odoo.sh. We developed an hybrid mode multi-workers multi-thread, the multi-workers being handled by the Odoo.sh platform, and the multi-threads being handled by the Odoo server.

So we cannot use this heuristic to determine wether the limits should be set to unlimited or not.

Besides sometimes a developer debug using multi-workers, and the limits should be dropped in this case too.

[fractalf]

Came across this while searching for what I think is a bug regarding --dev reload (issue).

Is there any relation to what is discussed here and the fact that if I use --dev reload (using 5 workers) the Event Service (longpolling) won't start?

The log when not using --dev reload

...
2019-11-26 14:25:07,012 23 INFO ? odoo: database: odoo@odoo-db:5432 
2019-11-26 14:25:07,645 23 INFO ? odoo.addons.base.models.ir_actions_report: Will use the Wkhtmltopdf binary at /usr/local/bin/wkhtmltopdf 
2019-11-26 14:25:08,295 23 INFO ? odoo.service.server: Evented Service (longpolling) running on 0.0.0.0:8072 

The log when using --dev reload

...
2019-11-26 14:22:06,912 32 INFO ? odoo: database: odoo@odoo-db:5432 
2019-11-26 14:22:07,546 32 INFO ? odoo.addons.base.models.ir_actions_report: Will use the Wkhtmltopdf binary at /usr/local/bin/wkhtmltopdf 
2019-11-26 14:22:07,656 32 INFO ? odoo.service.server: Watching addons folder /var/lib/odoo/addons/12.0 
2019-11-26 14:22:07,657 32 INFO ? odoo.service.server: Watching addons folder /usr/lib/python3/dist-packages/odoo/addons 

[blaggacao]

@fractalf I'm writing https://github.com/xoe-labs/dodoo to empower myself of disecting Odoo complexity quirks away from the server.

[blaggacao]

Specifically: https://github.com/xoe-labs/dodoo/blob/master/dodoo/README.md

[blaggacao]

@fractalf this is not a bug.

[fractalf]

@blaggacao can you please explain why this is not a bug? Why won't the longpolling service start when using --dev ?

[blaggacao]

Or is it? :-) I have spent too much time with Odoo quirks, something better is being conceived.

So, let's make it a cli spec:

• dodoo run bus <socket>
• dodoo run http <socket>

Saying: Let's throw away the essentially unmaintainable Odoo server middleware and built a better one.

Those kind of things only get worse when it comes to production deployments.

[pumppi]

Hi Guys, I have the same issue when trying to use it with docker. Any solutions?