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 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 _______________________________________________ Mailing list: https://launchpad.net/~openerp-india Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-india More help : https://help.launchpad.net/ListHelp
