[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* fix the gevent worker "logging" everything to stderr and ignoring
the logging configuration: passing loggers to WSGIServer means it
uses those loggers instead of writing directly to stderr
* fix the gevent worker logging the wrong client address when behind a
reverse proxy: it would log the client_address, immitate the
behaviour of werkzeug which goes and gets whatever REMOTE_ADDR is
set on the environment, that way it gets whatever update were
performed by ProxyFix (if any)
Fixes#32914closesodoo/odoo#36233
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
1. Make test logs clearer & remove redundancies
Instead of having an ERROR log right when the test fails then print
the useful / relevant information at the end of the test suite,
immediately print the traceback. Keep the final summary. Also avoids
having to wait for the entire test suite to end before a dev' can know
the failure details of a specific test.
Done by working at a lower level and replacing the custom
test stream mess by a custom Result class which prints and formats the
information we want. Replace TextTestRunner by a bare-bones custom
Runner object to tie it in.
2. Provide useful location information on test failure
Leverage the work above to log the test function's failure location:
previously logging would point to within TestStream which is not
useful.
Here, on failure the traceback is used to discover the caller info and
point to the test line which fails instead. similar to unittest's
_exc_info_to_string (https://github.com/python/cpython/blob/93e8aa62cfd0a61efed4a61a2ffc2283ae986ef2/Lib/unittest/result.py#L173).
3. Replace direct logging in browser_js by raising errors
Properly marks the test as in error, and the error traceback points to
the tour definition / launcher (python side) rather than common.py
and/or module.py.
Also removes unused dbname parameter that was added in
/278ed718e9805edf088642ba10d3b7c4e5716c31/openerp/modules/module.py#L361
for nor visible reason
closesodoo/odoo#34996
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We add two warnings to make the --test-file argument more user friendly:
- one when the test file does not exist
example:
./odoo-bin -d master --test-file ./addonss/stock/tests/test_quant.py
before:
INFO master odoo.service.server: loading test file ./addonss/stock/tests/test_quant.py
after:
WARNING master odoo.service.server: test file ./addonss/stock/tests/test_quant.py cannot be found
- one when the test file is not a python file
In both cases, nothing was being tested but the server did not say why.
closesodoo/odoo#34808
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
If a signal is received during the worker _runloop sleep,
the worker will be marked as alive=False but process_work
will still be called once.
This commit prevents that by checking the worker state before
calling process_work.
closesodoo/odoo#31885
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Avoid potential tracebacks from the FSWatcher's thread being killed.
Drawback: Server shut down can have an extra small delay
(only applies when the --dev=reload option is given)
closesodoo/odoo#31855
Signed-off-by: Christophe Simonis <chs@odoo.com>
Add the alternative of inotify instead of watchdog to watch the addons
paths the server was started with.
Reason: watchdog spawns 2 threads per path to watch. When there are a
lot of addons paths, this can become too costly. With inotify we watch
all the repositories in a single thread.
https://github.com/dsoprea/PyInotify
installation:
pip install inotify
Because Python only runs signal handlers on the main thread, native
calls (IO or accept(2)) can delay these handlers running. This is
especially problematic when one such call is completely stuck and
we're trying to dump the stack to diagnose the issue.
By running the actual worker's processing in a sub-thread and leaving
the main thread sleeping, worker processes should always be able to
handle signals.
closesodoo/odoo#30688
When Odoo is stopped using CTRL+C on Windows, a Traceback is thrown
because the SIGXCPU signal does not exists on Windows.
With this commit, the check for SIGXCPU only occurs on supported
platforms.
Fixes#33311closesodoo/odoo#33333
Signed-off-by: Christophe Simonis <chs@odoo.com>
The method override `_handle_request_noblock`
is there to solve a bug in Python socketserver library
which has been solved in
- Python 3.6: python/cpython@8b1f52b5a9,
- Python 3.7: python/cpython@9080824513,
through PR python/cpython#9952.
These revisions will be included in Python releases 3.6.8 and 3.7.2,
and the override will then become useless.
We therefore can remove the `_handle_request_noblock` override
as soon as the Python 3 releases installed on operating systems
supported by Odoo are above
- 3.6.8 for Python 3.6
- 3.7.2 for Python 3.7
closesodoo/odoo#29706
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
Cheery-pick of f9ee8cf to avoid runbot_merge failures.
closesodoo/odoo#28193
Previously broken symlinks would cause a FileNotFoundError
exception in the filesystem watcher thread spawned when using the
--dev=reload argument.
This problem appeared when using emacs to edit python files while
they are being watched by an odoo instance for changes. Emacs
creates a broken symlink as lockfile in the same directory as the
python file that it edits.
This commit makes the filesystem watcher silently ignore any
FileNotFoundError that occurs when it tries to open a file.
Fixes #21214, closes#21215
This revision aims to support the memory limits
on Linux, Windows and MacOSX according to their own spefication
regarding their memory management.
Among others, it brings the possibility to
use the multi-workers mode on Windows and MacOSX.
e.g.
- Windows does not support `resource`,
and therefore we skip to set the hard limit
- MacOSX allocates a large virtual memory for each process
even if the memory is not actually used,
and therefore using the VMS to limit the memory is pointless
as it will always exceeds the default soft memory limit.
We therefore choose to use the RSS to limit the memory
closesodoo/odoo#27848
Rev. dcb56412d6
introduces limits for the threadedserver
It uses `resource` to set the hard limit,
but unfortunately `resource` is not available on Windows.
As in the GeventServer, we therefore set the resource
hard limit within a `if os.name == 'posix'` block,
as in rev.
c68b41bff2
When Odoo intercept the SIGXCPU signal, an error message is written to
the stderr. Unfortunately, if stderr is redirected to a buffered file, the
message will not appear.
Before this commit, if import from tests directory was not in the __init__ file,
it was not possible to launch it with --test-file cli.
Now we only check in test directory if file exists.
This commit closes#26500
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
Do not reload when a temporary Python file is
added/updated/reloaded.
This is to be able to use editors using isolation when saving file.
On save, they create a temporary file which is then moved on the target file.
The temporary file exists for milliseconds only,
and when the change was detected by watchdog and the server was reloaded,
the file already no longer existed on load.
It leaded to `No such file or directory` after the reload.
Julien Castiaux