The `ImDispatch` thread uses the `thread.is_alive` method to check
whether or not the thread should be started. The issue is that, this
method will return `False` after the start method has been called, but
before the run method is invoked leading to the RuntimeError: thread
can only be started once.
This commit fixes this issue by suppressing this error in this case.
closesodoo/odoo#103157
X-original-commit: daded0125a4ec2421b9e817aaaa725da2fd96a20
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
When stopping the server, all cursors are closed. The issue is that
the ImDispatch thread is kept alive until the main thread exits.
This can lead to errors during server stop: the ImDispatch thread
could try to poll an already closed connection thus raising a
`psycopg2.InterfaceError` exception.
This commit solves the issue by hiding the interface error when
it occurs during server stop.
closesodoo/odoo#100002
X-original-commit: 83777078f1be093c218267c8282e8c11f4fb4e8d
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before the websockets were introduced, longpolling coroutines were
sleeping until postgres notify. Each coroutine was then wake up and
notifications were fetched.
Since the websocket introduction, the main loop, responsible for listening
to postgres sends the notifications itself. This means, the postgres loop
is blocked during message fetch/dispatching and notifications are dispatched
in a sequential fashion resulting in a slow message dispatching.
In order to solve this issue, websocket coroutines are now responsible to
fetch/dispatch notifications, letting the main loop free to relay notifications
as they come and allowing notifications to be sent simultaneously.
When instructed to dispatch available notifications, the websocket coroutines
will try to acquire a cursor. Each coroutine will try up to `MAX_TRY_ON_POOL_ERROR`
times, sleeping between each try. If no cursor can be acquired, the connection is
closed with the TRY_LATER` close code.
closesodoo/odoo#98880
Signed-off-by: Antony Lesuisse <al@odoo.com>
When a websocket is disconnected, its subscription is removed.
Each channel leads to a set of subscribed websockets. When no
more sockets are listening to a channel, this channel should be
pop from this mapping or the map will keep growing.
closesodoo/odoo#98766
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: hr_presence, web_editor.
This commit is part of the websocket integration in Odoo.
It focuses on adapting the bus to support websockets:
- last notification id is now kept on the server
- channel list is built by overriding the `_build_bus_channel_list`
method of the `ir_websocket` model instead of overriding the `_poll`
method of the bus controller.
- The bus presence was updated during polls, since there is no more poll,
bus presence update will be the responsability of the client.
- The `/websocket/peek_notifications`, `/websocket/update_bus_presence`
routes will be available so that odoo sh can access notifications/update presence
from http requests.
- /longpolling routes are now prefixed with /bus thus won't be redirected to the
gevent worker anymore except for `/longpolling/health` which is the
health check route of the gevent server.
Since websocket now handle incoming messages, a way to manage authentication
have been introduced :
- The session is retrieved from the HTTP handshake.
- When a websocket message comes/leaves the session is retrieved
on the file system so that we're sure it still exists and that
it is up to date.
- The session is checked
- If no session is found on the file system or `check_session`
fails, the websocket connection is closed with the `SESSION_EXPIRED`
close code (which is a custom close code: 4001).
- Note that websocket connections are closed every `KEEP_ALIVE_TIMEOUT`
seconds to ensure no websocket connection will stay open if the user
clears its cookies.
- Note that a wsrequest object is available when processing incoming
messages. It is similar to the http request and contains various
useful informations (session, env, ...).
Part-of: odoo/odoo#75510
In fixing leftover jammy warnings in #92078 I mistakenly updated the
setting of `_daemonic` to the public `daemon`, missing that it was a
dedicated and explicit workaround for Python's checks (cf
d03b4f8675).
closesodoo/odoo#92255
X-original-commit: e35a4d87578a588e33f604638289ca7e7ee02029
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Python 3.10 formally deprecated the old threading API. This was missed
in #88803.
Also apply a few other fixes and improvements:
- `Thread._daemonic` is a non-public unchecked internal attribute, use
the corresponding documented property
- remove unused assignment to unused local
- define `Event` attribute in `__init__` where it belongs
- cleanup spawning on thread to do everything in ctor (permissible
since 3.3)
- fix import to not rely in implicit sub-module imports
closesodoo/odoo#92187
X-original-commit: 87d087ff7d53394dd991099cf7eac37d1ef68423
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Start odoo in threading mode with bus installed. Login in the browser
using any internal user. Make sure the browser call the
/longpolling/poll uri. While the browser is waiting for a response, stop
the server. The server takes up to 50 seconds to stop.
When started in threading mode, a request to /longpolling/poll is served
by a casual http thread. It searches for messages enqueued in the bus
and returns them. If there are no message for the user in the queue yet,
it creates a `threading.Event`, attach it to the user in a shared
dictionnary and `wait()` on it with a timeout of 50 seconds (hardcoded
value). When the bus thread (the one responsible to listen on the
database) receives new messages, it `set()` the events which resume any
http thread that was waiting.
Because when we stop the server, there is no way to server new requests,
there are no way new messages arrive in the bus. All the threads that
were waiting for a new message will just wait until the event timeouts
which slow down the shutdown of the server.
Now we actively `set()` all events in order to resume all those workers
when we stop the server.
The `ImDispatch.poll` signature has been changed too so it is possible
to change (via code) the hardcoded default. The function was using the
object referenced by `TIMEOUT` at the time the function was defined,
using `timeout None` then `if None: timeout=TIMEOUT` ensures we lookup
the variable.
closesodoo/odoo#64530
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
When making a poll, an event is registered on each channel. Once
a notification is sent on a channel, only the events of the
notified channel are removed. A pointer to the event is kept
in all other channel the user subscribes to until those channel
are notified.
Since a user usually has many mail.channels but only a few active ones,
a new event and a bunch of pointers are created at each poll and
never removed.
This fix simply remove the pointers to the current event at the
end of a poll.
closesodoo/odoo#31215
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This commit is a refactoring of im_status management.
This commit also add im_status in two places, near the author in a mail thread and on each suggestion when using mentions.
A service to manage im_status will have multiple benefits here:
-centralise information, avoid to call the server multiple time for the same im_status
-update all im_status at once and keep consistency in display.
With this commit, the im_status updates are now done by rpc call.
Updates where previously made with the bus but this has some drawback,
since the bus will only give the information 50 seconds after the beginning of
the request, in the worst case, we van wait 2*50 seconds to get an update.
More than that, the im_status where only updates for pinned dm_chat. Dm chat
are synchronized cross tabs, making the use of the bus possible for this purpose.
Since we will need to display im_status not linked to dm_chat, the list to update
will be different from tab to tab making the use of bus difficult for this purpose.
Technical notes:
-im_search has been moved from bus to mail addons since it concerns mail.channel
-Update of an im_status should be reflected everywhere in the page.
Since im_status is a rendered template used in multiple widget, we should add
the correct logic to all concerened widget. The current solution is simple:
use a jquery selector to find every place where im_status is rendered.
-we add a new im_status: im_partner. This will indicate that that
the partner has no user linked to him, making it possible to avoid to ask
for status updates for this partner.
-The update will only be done when the tab is focused. (and will be done
asap once the tab get focus back)
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
Running the bus garbage collector synchronously during the handling of a
request can stall the request for a very long time.
Instead, we add this step to the existing auto-vacuum scheduled job that
handles this kind of housecleaning. It brings another interesting bonus:
it can be scheduled outside of peak hours, which will avoid blocking other
bus-related transactions (the GC deletes a lot of rows and takes a lot
of exclusive locks in the database)
closesodoo/odoo#28326
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
P3 got rid of all __private attributes in the `threading` module,
via python/cpython@d06489945f.
Our old code for forcing the `daemon` attribute on an already started
thread used the mangled private name and does not work anymore on P3.
We need to use the new private attribute name (actually both,
to keep backwards-compatibility w/ P2)
This might have deserved a pycompat counterpart, but setting both
variants of the attribute works with no hassle. It should not be a very
frequent use case either.
Add a `peek` option in the bus event dispatcher polling in order to let
an external event dispatcher fetch the notifications and their
corresponding channels.
Commit 5d1b323. re-enabled the user presence updates and notifications.
Unfortunately, it showed poor performance due to the high frequency of bus
notifications triggered on our instance (~600k users).
In this rev., we don't trigger notifications on presence changes anymore, but
we rather send the presence of users we have a DM open with, at the end of each
poll period. For performance reasons, we ensure not to do that more than once
every 30 seconds.
We also refined the detection of the 'away' status client side. 'Last presence'
timestamps are stored in the local storage, and the current inactivity period
is sent at each poll. Those presence timestamps now rely on browser activity
detection (click, keypress... events) rather than on the focus on Odoo tabs.
Finally, we removed the no more necessary cron introduced in 5d1b323.
If calling more than once `sendmany` (or `sendone`) on the same http request, the `NOTIFY imbus` will tell pertinent polling thread to
fetch their notifications in the bus table, which will not contain the new notifications, since they are not yet committed. For some reason, this
doesn't happen when calling only once `sendmany`. Committing the notifications breaks the tests since no rollback is possible.
So, `self._cr.commit()` should not be called in a test environement.
In this case, we cannot use `isinstance(self._cr, TestCursor)` since TestCursor is only avaiblable for http request in test mode. Here the cursor is a normal cursor, and to determine if we are in test mode, there is no other option than checking the config of the odoo server.
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
Migrate the models and controller to new API. Renaming xml id according to convention, renaming openerp tag into odoo tag. Add comment strings and documentations.
tsm-odoo