Changing company does not work properly with gunicorn

Bug #954907 reported by James Jesudason
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Fix Released
Low
OpenERP Publisher's Warranty Team

Bug Description

When OpenERP is running with multiple gunicorn workers, changing company after login does not work correctly.

To see the issue, create a database with multiple companies and have rules that limit the view of a set of records e.g. account.account, based on the company that you are logged into. You need your user Then start OpenERP with multiple gunicorn workers.

1. Once logged in, change company (in the Preferences dialog).
2. Go to a list of records that give a limited view based on the ir.rule e.g. account.account.
3. Keep refreshing the list by clicking the menu link that displays the record list.

Expected result:
Should only see the accounts for the company that you are logged into - every time that you click on the menu link.

Actual result:
Sometimes you see the accounts that you are logged into, other times you see the accounts from the previous company that you were logged into. Presumably, this is because you have only changed company in one of the gunicorn workers... not all of them. So OpenERP does not seem to be completely stateless when it comes to changing company.

Tags: maintenance
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello James,

I have checked this issue with latest trunk and It's working fine.

I have tried your same scenario with web client and when I am changing the company the view is automatically reloaded and you no need to click again the menu link. If you are using gtk then just reload/refresh the view.

I have attached a video for your more reference, So would you please check it and notify us where you have faced the problem.

Thanks and waiting for your reply!

Revision history for this message
Amit Parik (amit-parik) wrote :
Changed in openobject-server:
status: New → Incomplete
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Amit,

how many gunicorn processes where you running your test with?
did a request from a different gunicorn process return the views related to the new company_id?

From your video, it is not obvious that you have tested either of the above points. Hence you did not test the requested actions at all.
Please redo testing by:
1) starting gunicorn with e.g. 4 processes (more than 1 NB!) using the database in your video.
2) Change the company from the top right info drop-down
3) refresh the chart of accounts at least 8 times
4) result is that some of the times you will see new chart of accounts / some other times you will see old

Regards,

Dmitrijs.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

please, retest

Changed in openobject-server:
status: Incomplete → Confirmed
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Dmitrijs.

Thanks for your response on this.

Yes, you are correct I missed to start server with gunicorn.

Now I have re-test the same thing with gunicorn and I have started four different process means started with 4 workers.

I have reproduce the same thing at my end, but it's hard to reproduce because I didn't face the problem all time.

After more then 2 times changing the company from user preference, I have faced this issue also I have faced one error of "Deleted document" (may be this error occurs due to record rule but this error doesn't occurs If I start my server normally.)

I have attached a video which is more helpful for producing this issue, So please check it.

Thanks for understanding!

Revision history for this message
Amit Parik (amit-parik) wrote :
Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Medium
importance: Medium → Low
Revision history for this message
James Jesudason (jamesj) wrote :

Is there any progress on this bug? This is quite a major issue and really holds back the use of gunicorn for any company that is using multi-company.

Revision history for this message
James Jesudason (jamesj) wrote :

> I have reproduce the same thing at my end, but it's hard to reproduce because I didn't face the problem all time.

The reason that you don't face the same problem every time is because it depends which gunicorn worker process is used for each call.

For example, if you have 4 gunicorn workers and a database with 2 companies (Company A and B). Say that you login to 'Company A', and the initial login request goes through worker 1. As you continue to navigate OpenERP, requests will go through any of the workers (1-4), and they will all think that you are logged into 'Company A'... which is correct.

Then, if you switch to "Company B" in Preferences, then that request will get sent through a worker (let's say worker 2). So now, worker 2 knows that you are in 'Company B', but actually workers 1, 3 and 4 think you are in 'Company A'. So if you request a company-specific document, then it depends which worker processes the request whether you will see the document of not. So, if the request goes through worker 2, you're lucky and can see the document. However, if request is sent through worker 1, 3 or 4, then you will get an error (the "Deleted document error) as those workers think that you are logged into "Company A".

The problem is that OpenERP is not stateless when it comes to changing company.

Changed in openobject-server:
assignee: OpenERP's Framework R&D (openerp-dev-framework) → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
Revision history for this message
Xavier ALT (dex-phx) wrote :

Hi,

Please note that the cache invalidation problem was solved two month ago by this server revision:

  <email address hidden>

Cheers,
Xavier

Changed in openobject-server:
status: Confirmed → Fix Released
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.