Server crashes (or takes several minutes to respond) when searching through a large amount of contacts

Bug #1190217 reported by Olivier Laurent (Acsone)
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Status tracked in Trunk
7.0
In Progress
Medium
OpenERP Publisher's Warranty Team
Trunk
Confirmed
Medium
OpenERP's Framework R&D

Bug Description

With about 200.000 res_partner records in the database, when searching for name with "some" inexisting patterns:
- the server takes more than 4 minutes to respond with an empty list of results (tested on a windows machine double core with 3G of memory), or
- the server stops running without special message in the openerp.log file (tested on an Ubuntu machine double core with 2G of memory) producing the following message in the web browser:

XmlHttpRequestError Service Temporarily Unavailable
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Temporarily Unavailable</title>
</head><body>
<h1>Service Temporarily Unavailable</h1>
<p>The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.</p>
<hr>
<address>Apache/2.2.22 (Ubuntu) Server at ...</address>
</body></html>

Tested on branch lp:~openerp/openobject-server/7.0

Steps to reproduce:
- restore the attached database dump
- logon with admin/admin credentials
- go to sales/sales/customers
- in the search box, rid off the "Customers" filter and type @, then accept the first option, i.e, "Search Name for: @"

Tags: maintenance
Revision history for this message
Olivier Laurent (Acsone) (olivier-laurent) wrote :
Revision history for this message
Twinkle Christian(OpenERP) (tch-openerp) wrote :

Hello Olivier,

I have also tested this issue on Ubuntu 12.04. And when I were restore your database and then try to "search name for:@" system is becoming hang and server takes more 20 min to respond.

So, that's why I am confiming this issue.

Thank you.

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Olivier Laurent (Acsone) (olivier-laurent) wrote :

Similary, the same symptom also appears when trying to add email addresses to a Mass Mailing or to add followers to a document.

Steps to reproduce:
- use also the attached database dump
- install the "Social Network" app
- go to Sales/Customers
- edit an existing partner
- click on "Add others" link in the followers zone of the screen
- in the "Partners" list in the email popup, choose "Search More..."

Application never responds or after a waiting period of about 4 minutes.

The same scenario from the "Mass Mailing" feature produces exactly the same effect.

tags: added: maintenance
Revision history for this message
Stéphane Bidoul (Acsone) (sbi) wrote :

Hello,

Thank you for the fast reaction. Replacing browse by read will certainly improve the performance.

Don't you think, however, that the root cause would be higher up in the chain? There should be no reason to call name_get with so many ids.

-sbi

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :
Revision history for this message
Olivier Laurent (Acsone) (olivier-laurent) wrote :

Hello,

In addition to lp:~openerp-dev/openobject-server/7.0-opw-593963-rha, we suggest another improvment in lp:~olivier-laurent/openobject-server/7.0-bug1190217.

Applying the 2 patches, the respond time becomes almost "immediate" (about 1 or 2 secs) in the treeview (or kanbanview) of the partners.

In any case, respond time of the "Search More..." option of the email popup of the "Mass Mailing" and the "Add Followers" features remains important, about 7 or 8 seconds to show a list of 80 partners.

Olivier

Revision history for this message
Naresh(OpenERP) (nch-openerp) wrote :

Hello All,

The name_get will receive a limit of 8 only to fill up the drop down list as we type in the letters in the search box. In
this case '@' sign but as it want find any match it returns the 0 result. Then when we press Enter to search on the name ilike '@' the search is called with limit=40 and the domain is added as ['|','|', ['name', 'ilike', '@'], ['parent_id', 'ilike', '@'], ['ref',
'=', '@'] ] so now the normal search will be called which will try to build this domain using expression.py so when it encounters a relation field it does a name_search with limit=None, 'ids2 = [x[0] for x in relational_model.name_search(cr, uid, right, [], operator,context=context, limit=None)]'. The limit=None in this is needed as we need to search on the relational table too.

So to fix this we can remove the relational field from the domain i.e ['parent_id', 'ilike', '@'] and place it in the name_search query explicitly will improve the speed as the extra relational name_search will not be called with all the limit=None.

The new part will be added to the merge proposal (https://bugs.launchpad.net/+branch/~openerp-dev/openobject-server/7.0-opw-593963-rha) soon.

Thanks,
Naresh Soni,
OpenERP Enterprise Services

Revision history for this message
Rifakat Husen (OpenERP) (rha-openerp) wrote :

Hi Stéphane and Olivier ,

Thanks a lot for your detail analysis. You caugth the exact point. name_get() should get limited ids but it is
name_search() for relational field(parent_id) which causes problem.

As Naresh explained we can solve this problem by removing parent_id from search domain as parent_id search
is already taken care by `res.partner` name_search() query. It explicitly matches search name with parent so
removing parent_id from domain should not be a problem.

Thanks a lot for your fix Olivier, but don't you think below could be a simple fix?
http://bazaar.launchpad.net/~openerp-dev/openobject-server/7.0-opw-593963-rha/revision/5014

Please let me know if you face any difficulty.
I really appreciate your co-operation.

Regards,
Rifakat

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.