openerp-india team mailing list archive

[Marcos Mendez <marcos@xxxxxxxxxxxx>]

Hi,

Is there some code/example about how to make a user a manager of a
group? I'm trying to automate the creation of users to do this test
properly. I can create the user, but just assigning group_ids is not
enough when creating the user.

For example:
# CREATE USER
data = {
#'groups_id': [9, 2, 8, 19, 23, 21, 13, 11, 17, 7, 12, 18, 20, 1, 22, 3],
'password': 'test', 
'active': True, 
'name': 'Test', 
'login': 'test', 
}

sock = xmlrpclib.ServerProxy('http://%s:8069/xmlrpc/object'%host)
id = sock.execute(dbname, uid, pwd, model, 'create', data)


On Jun 18, 2012, at 11:25 AM, Marcos Mendez wrote:

> Agreed. I will modify the test bias and send updates. We will also have automated systems, so this was trying to simulate that also. We can do the login once. I just expect OpenERP to handle a normal load. So will change the test to remove that bias.
> 
> Thanks
> 
> On Jun 18, 2012, at 9:59 AM, Olivier Dony (OpenERP) wrote:
> 
>> On 06/18/2012 03:20 PM, Marcos Mendez wrote:
>>> Basically, ten users trying to create a partner at the same time will
>>> fail - not all will work. I have provided the instructions on how to
>>> reproduce the error with JMeter. There are many errors in the log.
>>> 
>>> Please revisit this. I would hope that OpenERP can handle more than 5-8
>>> concurrent users doing reads and writes.
>> 
>> It seems your test is heavily biased. Unless I missed something, you are:
>> - simulating concurrent users that are all using the same login
>> - making the virtual users login before each request
>> 
>> The login call that is performed before each query is not only unnecessary but
>> will also cause an update to the user record in the database (to change the
>> last login time). And because all users are sharing the same login, this can
>> cause concurrent transactions to be invalidated due to potential conflicts on
>> the shared user record.
>> 
>> Please take these two factors out of the equation and see if you can reproduce
>> the problem.
>> 
>> It is valid to perform batch transactions using a unique login, e.g. for web
>> services integration, but if you do that in production you'll want to pay
>> attention to the following:
>> - No need to call login() every time, it's only used to get the user id (and
>> update the last login time, which you don't care about in this context)
>> - You *have to* implement a transaction queue, and implement appropriate error
>> handling! Things could go wrong anywhere in the flow: network, hardware, disk
>> space, database server, openerp server -> you *must* handle the various cases
>> appropriately, or you're asking for trouble in the future. In most cases the
>> solution will be to requeue the request, and this will work as well for the
>> error we're discussing here, if it ever happens.
>> 
>> PS: bug 1013223 does seem to be a duplicate of this bug
>> 
>> -- 
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (1013223).
>> https://bugs.launchpad.net/bugs/992525
>> 
>> Title:
>> TransactionRollbackError due to concurrent update could be better
>> handled
>> 
>> Status in OpenERP Server:
>> Confirmed
>> 
>> Bug description:
>> While using openerp, psycopg2 raises TransactionRollbackError quite
>> often even on small database.
>> 
>> This does not seem to be easily reproduceable as it seems to be a
>> conflict between two thread accessing the same table. Nevertheless, I
>> provided a quick video reproducing this while installing "base_crypt"
>> on my computer.
>> 
>> This occurs mostly at module installation. And can completely mess up
>> the module installation by giving empty wizard windows of instance.
>> 
>> I guess it could also occurs in other situations (in multi-user
>> context), where the bug would be quite difficult to reproduce and with
>> unforeseeable consequences ;)
>> 
>> I've spotted an other bug that is due to this it seems:
>> https://bugs.launchpad.net/bugs/956715
>> 
>> In my case (single user), it seem to hit more often on fast computers.
>> To make a probable better guess, it seems to hurt more often whenever
>> using a local connection between the browser and the server. It could
>> be about the web module trying to update the res_users session info
>> and may collide with normal operation.
>> 
>> On my computer, from a new database, installing the 'base_crypt' will trigger the exception.
>> When using a distant connection, the bug won't show up.
>> 
>> Please check the video I've posted with the bug report if you want to
>> have more detail on the procedure I used. Sorry for the bad sound
>> recording. Note that the video will show you the bug occuring on my
>> computer and NOT occuring on a distant computer.
>> 
>> I'm providing a merge proposal along with this patch which solves the
>> issue for me, but need a patient review.
>> 
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/openobject-server/+bug/992525/+subscriptions
>

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/992525

Title:
  TransactionRollbackError due to concurrent update could be better
  handled

Status in OpenERP Server:
  Confirmed

Bug description:
  While using openerp, psycopg2 raises TransactionRollbackError quite
  often even on small database.

  This does not seem to be easily reproduceable as it seems to be a
  conflict between two thread accessing the same table. Nevertheless, I
  provided a quick video reproducing this while installing "base_crypt"
  on my computer.

  This occurs mostly at module installation. And can completely mess up
  the module installation by giving empty wizard windows of instance.

  I guess it could also occurs in other situations (in multi-user
  context), where the bug would be quite difficult to reproduce and with
  unforeseeable consequences ;)

  I've spotted an other bug that is due to this it seems:
  https://bugs.launchpad.net/bugs/956715

  In my case (single user), it seem to hit more often on fast computers.
  To make a probable better guess, it seems to hurt more often whenever
  using a local connection between the browser and the server. It could
  be about the web module trying to update the res_users session info
  and may collide with normal operation.

  On my computer, from a new database, installing the 'base_crypt' will trigger the exception.
  When using a distant connection, the bug won't show up.

  Please check the video I've posted with the bug report if you want to
  have more detail on the procedure I used. Sorry for the bad sound
  recording. Note that the video will show you the bug occuring on my
  computer and NOT occuring on a distant computer.

  I'm providing a merge proposal along with this patch which solves the
  issue for me, but need a patient review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/992525/+subscriptions