AttributeError: 'str' object has no attribute 'get'

[Milan Tribuson]

Hi!

I'm using openerp server v5.0.14 and i sometimes get an error when I select something on the main menu of the web-client:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line 299, in dispatch
    result = LocalService(service_name)(method, *params)
  File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line 77, in __call__
    return getattr(self, method)(*params)
  File "/usr/lib/python2.5/site-packages/openerp-server/addons/audittrail/audittrail.py", line 341, in execute
    return fct_src(db, uid, passwd, model, method, *args)
  File "/usr/lib/python2.5/site-packages/openerp-server/addons/base_module_record/base_module_record.py", line 38, in execute
    res = super(recording_objects_proxy, self).execute(*args, **argv)
  File "/usr/lib/python2.5/site-packages/openerp-server/service/web_services.py", line 577, in execute
    res = service.execute(db, uid, object, method, *args)
  File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line 58, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line 119, in execute
    res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line 111, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/usr/lib/python2.5/site-packages/openerp-server/osv/orm.py", line 1291, in fields_view_get
    view_ref = context.get(view_type + '_view_ref', False)
AttributeError: 'str' object has no attribute 'get'

It happens randomly and without any cause. I don't know if it happens in the gtk client too but I could check the next time it happens. After I restart the server everything works fine. Anyone any idea?

[Damir Tušek (damir-tusek)]

Mile, ajd reci čovjeku da klikne na izračunaj i bit će mu sve ok...

2011/1/12 Mile Infokom <email address hidden>

> Public bug reported:
>
> Hi!
>
> I'm using openerp server v5.0.14 and i sometimes get an error when I select
> something on the main menu of the web-client:
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line
> 299, in dispatch
> result = LocalService(service_name)(method, *params)
> File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line 77,
> in __call__
> return getattr(self, method)(*params)
> File
> "/usr/lib/python2.5/site-packages/openerp-server/addons/audittrail/audittrail.py",
> line 341, in execute
> return fct_src(db, uid, passwd, model, method, *args)
> File
> "/usr/lib/python2.5/site-packages/openerp-server/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File
> "/usr/lib/python2.5/site-packages/openerp-server/service/web_services.py",
> line 577, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line
> 58, in wrapper
> return f(self, dbname, *args, **kwargs)
> File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line
> 119, in execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/usr/lib/python2.5/site-packages/openerp-server/osv/osv.py", line
> 111, in execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/usr/lib/python2.5/site-packages/openerp-server/osv/orm.py", line
> 1291, in fields_view_get
> view_ref = context.get(view_type + '_view_ref', False)
> AttributeError: 'str' object has no attribute 'get'
>
> It happens randomly and without any cause. I don't know if it happens in
> the gtk client too but I could check the next time it happens. After I
> restart the server everything works fine. Anyone any idea?
>
> ** Affects: openobject-server
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> OpenObject Server.
> https://bugs.launchpad.net/bugs/701914
>
> Title:
> AttributeError: 'str' object has no attribute 'get'
>
> Status in OpenObject Server:
> New
>
> Bug description:
> Hi!
>
> I'm using openerp server v5.0.14 and i sometimes get an error when I
> select something on the main menu of the web-client:
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line
> 299, in dispatch
> result = LocalService(service_name)(method, *params)
> File "/usr/lib/python2.5/site-packages/openerp-server/netsvc.py", line
> 77, in __call__
> return getattr(self, method)(*params)
> File
> "/usr/lib/python2.5/site-packages/openerp-server/addons/audittrail/audittrail.py",
> line 341, in execute
> return fct_src(db, uid, passwd, model, method, *args)
> File
> "/usr/lib/python2.5/site-packages/openerp-server/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).exe...

[xrg (xrg)]

On Wednesday 12 January 2011, you wrote:
> Mile, ajd reci čovjeku da klikne na izračunaj i bit će mu sve ok...

> > view_ref = context.get(view_type + '_view_ref', False)
> >
> > AttributeError: 'str' object has no attribute 'get'
> >
> > It happens randomly and without any cause. I don't know if it happens
> > in the gtk client too but I could check the next time it happens.
> > After I restart the server everything works fine. Anyone any idea?

somebody/thing is passing down a str as the context. Or mis-placed positional
args. Why is this happening?

Perhaps a DEBUG_RPC trace could help a bit.

[Milan Tribuson (milan-infokom)]

I think it is happening about every 24 hours and it may be due to postgresql autovacuum process? When this bug happens i have two processes active on database: postgres autovacuum launcher process and postgres: writer process.
They use all of the system cpu and memory, is it due to that? There is nothing in postgresql.conf file for autovacuum jobs, is it done by default?
I've tried searching for it in database but i have not pg_autovacuum table?
Anyone know anything about it?

[Milan Tribuson (milan-infokom)]

I see that pg_autovacuum is not available in version 8.4 i'm working with. Autovacuum is commented with # in postgresql.conf so I suppose that there is a default job for autovacuum created or something?

[Olivier Dony (Odoo) (odo-openerp)]

Mile, as xrg says this is more likely an issue with an invalid RPC request sent to the server. Normally the current database state or postgresql autovaccum should not have any direct link with this.

You could you turn on the RPC logging of your server (by starting it with --log-level=debug_rpc) to see what parameters are passed to the fields_view_get() method by the web client when this occurs...

[xrg (xrg)]

On Friday 14 January 2011, you wrote:
> You could you turn on the RPC logging of your server (by starting it
> with --log-level=debug_rpc) to see what parameters are passed to the
> fields_view_get() method by the web client when this occurs...

Well, Olivier, we can even change the level at runtime, can't we ? ;)

Look at server/tools/change-loglevel.sh

[Milan Tribuson (milan-infokom)]

Will that slow down the server? It seems strange to me that it works fine and then it gets stuck randomly... So, Olivier, xrg, what is the best way to test this?

[xrg (xrg)]

On Sunday 16 January 2011, you wrote:
> Will that slow down the server? It seems strange to me that it works
> fine and then it gets stuck randomly... So, Olivier, xrg, what is the
> best way to test this?

DEBUG_RPC does slow down the server, just a little bit. That is, because it
needs to send all RPC data to the logger (either console or file).

[Milan Tribuson (milan-infokom)]

Ok, i've done that and now the log is filling up nicely:) I'll post it when the server freezes...

[Milan Tribuson (milan-infokom)]

No chance, log file was about 600MB after less than an hour work and it slowed down the server dramatically... After turning the log off server speed was fine... Any other ideas?

[Milan Tribuson (milan-infokom)]

I've managed to turn on the debug_rpc after the menu has crashed and here is the log. It is a little difficult to search through it because there were more than 40 users trying to work at the same time.
I've also tried using gtk client and it works fine so it is a web-client error? Here is a log, hope it helps... It is big so i suggest searching for: AttributeError: 'str' object has no attribute 'get'

[xrg (xrg)]

On Wednesday 19 January 2011, you wrote:
> I've managed to turn on the debug_rpc after the menu has crashed and here
> is the log. It is a little difficult to search through it because there
> were more than 40 users trying to work at the same time. I've also tried
> using gtk client and it works fine so it is a web-client error? Here is a
> log, hope it helps... It is big so i suggest searching for:
> AttributeError: 'str' object has no attribute 'get'
>
>
> ** Attachment added: "debug_rpc log"
>

Problem located at lines 8026, 8778, 8789, 11444 etc..

You see, that last parameter to ir.ui.view.read() , ir.ui.menu.read() should
have been a *dict* value of the context. Instead, it mysteriously appears to
be a string (most probably the str() = repr()=.. of that dict).

We shall first investigate the client, can you tell us exactly which clients
might be accessing that server?

[Milan Tribuson (milan-infokom)]

Gtk-client 5.0.14 and 5.0.15 are installed on client computers. I'm not sure about the web client, i think it is 5.0.12 but I'll check

[Milan Tribuson (milan-infokom)]

Just a note that gtk client works fine...

[Milan Tribuson (milan-infokom)]

Yes, it is 5.0.12

[Milan Tribuson (milan-infokom)]

Any news? This bug happens almost every day...

[Milan Tribuson (milan-infokom)]

Another crash today, our client is very unhappy. I'm sure it is a problem with web client 5.0.12 because gtk client works fine. After I restart openerp-web service and then openerp-server service everything works fine

[Milan Tribuson (milan-infokom)]

We already had 3 crashes today... I'm just wondering if anybody is trying to resolve this?

[Olivier Dony (Odoo) (odo-openerp)]

Hello Mike,

After looking at the log file you provided (very useful, thanks), it seems that the web client you are using (5.0.12?) ends up in a bad state at some point with a context value being a string instead of a dictionary.
Without a more precise scenario, it is very difficult to find the source of this problem.

Here are some additional hints that could help:
- Only one single login session should be impacted when this happens. This means that you should not need to restart the server at all, and not even the web client either. Doing a simple logout of the crashed session and logging in back should be enough.
- If you can't access the logout link after the session is crashed, you should be able to simply bookmark the URL or type it manually, it has the form: http://your-server-address:8080/logout

Now in order to make progress, we really need to narrow down the cases where this happen. Given that this seems to happen very often, could you try to write down a short list of the usual operations that were performed on crashed sessions right before the "crash"? It should be local to the session, so the operations performed by other users should not matter here.
We may be able to see a pattern in this short-list, and then track down the issue further.

Hope this helps...

[Milan Tribuson (milan-infokom)]

Hi Olivier!

This happens to all sessions that are logged through web-client (5.0.12) and not only to one. Even when someone who wasn't connected has the same error when he or she logs in through web-client. So, logging out and logging back in doesn't resolve the problem.
It is very difficult to write down the list of operations when this happens because we have 50-70 users working all around the country.

[Olivier Dony (Odoo) (odo-openerp)]

Hrm, this is very strange indeed. So you're saying that when this error occurs it affects all users currently connected to the system via web client, but not anyone who is using the GTK client?
That would mean that the context is being corrupted for all uses of the web client, and that is very hard to understand, as the context is stored per-session. On the other hand if the issue was server-side, GTK clients would be affected too.

To narrow down the issue, does the problem disappear if you only restart the web client service (and have users login again of course, since their session is lost)? Or else, does it perhaps disappear if you only restart the server (but not the web client), and ask users to logout to cleanup their session and start again?

Something else I noticed is that you are apparently using both the audit_trail and base_module_record modules, which can both listen to all transactions being processed at server-side... i.e. they have a global effect. Perhaps this is related to your issue in some way... even though I don't see any obvious connection.

Do you perhaps remember when the problem started to occur, if it was not always there? Was it after an update of the server, web client, both? Or perhaps after you installed some module(s)?

Does any of the above seem to ring a bell?

[Milan Tribuson (milan-infokom)]

Yes, it affects all users currently connected to the system via web client, and gtk is fine. The problem dissapears when I restart web service and after that server service and when users log in again. Restarting only web service didn't work but maybe i wasn't patient enough and maybe it would work with restarting only web service. The problem is that "time is money" and everything has to be done fast because users are waiting.
I know that we use audit_trail module in purchase but don't know if we are using base_module_record, I'll have to check. Base_module_record is for module recorder, right? If we aren't using it I could try to uninstall it.
The problem started when people started working with OpenERP. We didn't have this problem while we were developing as there were only few of us working but it seems that this problem occurs when there is more users working on system?

[Olivier Dony (Odoo) (odo-openerp)]

Yes, base_module_record is the module recorder. I only mentioned it because it is visible in the error tracebacks of your logs, but it may be totally unrelated to your problem.
Thanks for the other feedback. Of course if the error started to occur as soon as you went in production it won't give us any timing info as to when the problem appeared.

Normally restarting the server service should not be needed because OpenERP server is stateless and will not store any info about the sessions, especially not the session context. The usual places where the session context is stored are:
- the session storage in the web client service (which is stateful)
- the web pages displayed in the user browser
Restarting the web client service and asking users to login again clears these 2 places, so it should be sufficient normally.

[Olivier Dony (Odoo) (odo-openerp)]

BTW, the web client output/logfiles at the time when the error occurs might provide more information too, like when the web client starts to experience trouble accessing or altering a session's context, etc.

[Olivier Dony (Odoo) (odo-openerp)]

(Correcting status, as we are still unable to reproduce with the information we have so far)

[Milan Tribuson (milan-infokom)]

Forgot to tell you that we've abandoned web client on this installation so you can close this bug

[Amit Parik (amit-parik)]

Hello Milan,

Thanks for your reply!

According to your comment#26, I am closing this issue.

Thanks!

[Damir Tušek (damir-tusek)]

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Damir

Damir Tusek
ERP Consultant at Infokom d.o.o.
Croatia

Confirm that you know Damir Tusek:
https://www.linkedin.com/e/t21q58-h0kn9qco-1s/isd/6533512480/CP1lpWo6/?hs=false&tok=1YcQBTLyFO75c1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/t21q58-h0kn9qco-1s/GN5c8BACAPyDbCp60ub_zmZCyYQbmvVASPmnGor/goo/701914%40bugs%2Elaunchpad%2Enet/20061/I2266087994_1/?hs=false&tok=35d9fegB5O75c1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

[Emmanuel HURET (huret-emmanuel)]

I have the same problem. When it's append, we restart web service and it's ok. But we restart webservice 4 ou 5 times each day... Can this append with wrong version of cherrypy ?