busy cursor for switching form <-> tree

[Ferdinand]

sometimes it takes quite long to switch and there is no indication that koo is working
suggestion: busy cursor
see also
https://bugs.launchpad.net/bugs/396878

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

The busy cursor is already shown on switch view. What I've seen lately is that sometimes it takes a long time (switching from list to form in the partner view) due to the sorting of functional fields. Koo expects the server to raise an exception which is properly handled in the client (and it used to be very fast), but new versions of OpenObject try to obtain information from bazaar when the exception is thrown. This causes, in many cases a looong delay which I think should be fixed in the server.

[Ferdinand (office-chricar)]

I hope you filed a bug against the server

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

A Dilluns, 10 d'agost de 2009, Ferdinand @ ChriCar va escriure:
> I hope you filed a bug against the server

Not yet.

--
Albert Cervera i Areny
http://www.NaN-tic.com
Mòbil: [phone]

[Ferdinand (office-chricar)]

there must be also something on the client side
I get 100% CPU load and extreme disc activity

[Ferdinand (office-chricar)]

r 997
sorry to say - it's a show stopper
waiting 30-60 seconds is a No Go

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

I've eventually reported the problem and a patch to openobject-server. Le'ts see if it gets accepted:

https://bugs.launchpad.net/openobject-server/+bug/414393

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

Fixed in r999. In case the patch it's not accepted or it takes a long time, you can update your 'koo' server module and it will work without problems. If it's evenutally fixed in the server, we can remove the hack introduced in this revision.

[Ferdinand (office-chricar)]

sorry not completely - CRM crashes
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/Koo/Rpc/Rpc.py", line 407, in execute
    return self.call(obj, method, *args)
  File "/usr/lib64/python2.6/site-packages/Koo/Rpc/Rpc.py", line 393, in call
    value = self.connection.call(obj, method, *args)
  File "/usr/lib64/python2.6/site-packages/Koo/Rpc/Rpc.py", line 136, in call
    result = self.singleCall( obj, method, *args )
  File "/usr/lib64/python2.6/site-packages/Koo/Rpc/Rpc.py", line 126, in singleCall
    result = self.proxy.dispatch( obj[1:], method, self.databaseName, self.uid, self.password, *encodedArgs )
  File "/usr/lib64/python2.6/site-packages/Pyro/core.py", line 392, in __call__
    return self.__send(self.__name, args, kwargs)
  File "/usr/lib64/python2.6/site-packages/Pyro/core.py", line 462, in _invokePYRO
    return self.adapter.remoteInvocation(name, Pyro.constants.RIF_VarargsAndKeywords, vargs, kargs)
  File "/usr/lib64/python2.6/site-packages/Pyro/protocol.py", line 429, in remoteInvocation
    return self._remoteInvocation(method, flags, *args)
  File "/usr/lib64/python2.6/site-packages/Pyro/protocol.py", line 529, in _remoteInvocation
    answer.raiseEx()
  File "/usr/lib64/python2.6/site-packages/Pyro/errors.py", line 72, in raiseEx
    raise self.excObj
KeyError: 'date'
 +--- This exception occured remotely (Pyro) - Remote traceback:
 | Traceback (most recent call last):
 | File "/usr/lib64/python2.5/site-packages/Pyro/protocol.py", line 669, in _handleInvocation2
 | res = obj.Pyro_dyncall(req[1],flags,req[3]) # (method,flags,args)
 | File "/usr/lib64/python2.5/site-packages/Pyro/core.py", line 108, in Pyro_dyncall
 | return getattr(self.delegate or self,method) (*args,**keywords)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/addons/pyro.zip/pyro/pyro.py", line 47, in dispatch
 | result=method(*args)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/addons/base_module_record/base_module_record.py", line 38, in execute
 | res = super(recording_objects_proxy, self).execute(*args, **argv)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/addons/audittrail/audittrail.py", line 361, in execute
 | res = my_fct(db, uid, passwd, object, method, *args)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/addons/audittrail/audittrail.py", line 351, in my_fct
 | return fct_src(db, uid, passwd, object, method, *args)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/service/web_services.py", line 583, in execute
 | res = service.execute(db, uid, object, method, *args)
 | File "/data/downloads/bzr/branch/server/5.0/bin/osv/osv.py", line 59, in wrapper
 | return f(self, dbname, *args, **kwargs)
 | File "/data/downloads/bzr/branch/server/5.0/bin/osv/osv.py", line 119, in execute
 | res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
 | File "/data/downloads/bzr/branch/server/5.0/bin/osv/osv.py", line 111, in execute_cr
 | return getattr(object, method)(cr, uid, *args, **kw)
 | File "/home/terp/OpenERP/branch/server/5.0/bin/osv/orm.py", line 1250, in fields_view_get
 | xarch, xfields = self.__vie...

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

Should be fixed in r1000.

[Ferdinand (office-chricar)]

half way - tree 2 form works fast now ( the first switch )
all subsequent switches 30-60 seconds 100% CPU usage

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

It works ok for me. Can you tell me in what model you see that behaviour and send any error messages that might appear in the server log?

[Ferdinand (office-chricar)]

sorting a list with 100000 records
50% of the time the cursor shows busy -
then the cursor switches to idle for about 50% of the time

same for calling the form from them menu - I thought i'ts dead
monitoring the ethernet connection
* click on menu list form with 100000 records - focus remains on menu form - no busy cursor for almost 10 seconds - data transfer - switch to form - display records
client caching is on