c2c-oerpscenario team mailing list archive

[Raphaël Valyi - http://www.akretion.com <724961@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Hello,

I'll mark that bug as incomplete as for now, I have only suspicion but
no solid proof. But as early sharing is better than nothing, here is my
test scenario that produced scary results:

on a v6.0.1 production server, I had to drop 250 orders from a Magento import of year 2010 (cause not paid actually, just for later business intelligence analysis).
As it's impossible to drop confirmed pickings, with a 5 lines OOOR script (I trashed away), I was doing using the XML/RPC API:

for each order name to drop:
search the order by the name. -> OK
find out their picking (by origin name) -> OK
write state = 'draft' in those pickings -> KO sometimes
unlink the picking -> OK if previous OK
write state = 'draft' in those orders -> KO sometimes
unlink the order -> OK if previous OK

The real strange thing is I was doing something very simple, equivalent to:
self.pool.get('stock.picking').write(cr, uid, [picking_id], {'state': 'draft'})
self.pool.get('sale.order').write(cr, uid, [order_id], {'state': 'draft'})
but using OOOR, so XML/RPC calls under the hood.
I checked, the XML/RPC call was really OK

What happened is that sometimes, the write {'state': 'draft'} wasn't actually performed in the database!!
I could then check reading the record using OOOR or directly in the ERP via GTK (+refresh of course), pickings or orders where still confirmed.

This was totally inconsistent. Running the exact same code again, would
go a little further and process some more orders.

Also, something that also proved my OOOR code was right is that by just
introducing a sleep(0.5 secs) before the write call, suddenly I had no
more error at all!

Also, by running the server in log-level=debug_rpc, I could check that the server really received the 'write' call properly.
It was even answering True to the call, but not writing it in the database as expected.

This might never have been in production before because GTK or
webclients manual manipulations will wait a bit before sending more
write calls.

Also, OOOR trunk RSpec test suite fails in some ways that I found
inconsistent with v6 (redoing the same operation that failed worked
later). On the contrary OOOR 1.4.2 had always no failure with OpenERP
V5. Unfortunately I had no time to investigate it further.


Yesterday I tried to made a loop that call write on the name partner field using XML/PRC from Python on a localhost and write a different value each time. Then I was doing a read to check the value was the one I wrote. It was working always both from Python or OOOR. So so far I wasn't able to reproduce the problem simply.
May be it's linked to the object/field I was writing, may be it's linked to the fact the host is remote. Or may be it's even an OOOR trunk bug though I stringly doubt about that as log-level=debug_rpc proved me the proper calls where received by the server.


This is definitely worth a double check.
Can anyone confirm this issue?

** Affects: openobject-server
     Importance: Medium
         Status: Incomplete

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/724961

Title:
  [6.0.1] possible WS inconsistency under high load.

Status in OpenERP Server:
  Incomplete

Bug description:
  Hello,

  I'll mark that bug as incomplete as for now, I have only suspicion but
  no solid proof. But as early sharing is better than nothing, here is
  my test scenario that produced scary results:

  on a v6.0.1 production server, I had to drop 250 orders from a Magento import of year 2010 (cause not paid actually, just for later business intelligence analysis).
  As it's impossible to drop confirmed pickings, with a 5 lines OOOR script (I trashed away), I was doing using the XML/RPC API:

  for each order name to drop:
  search the order by the name. -> OK
  find out their picking (by origin name) -> OK
  write state = 'draft' in those pickings -> KO sometimes
  unlink the picking -> OK if previous OK
  write state = 'draft' in those orders -> KO sometimes
  unlink the order -> OK if previous OK

  The real strange thing is I was doing something very simple, equivalent to:
  self.pool.get('stock.picking').write(cr, uid, [picking_id], {'state': 'draft'})
  self.pool.get('sale.order').write(cr, uid, [order_id], {'state': 'draft'})
  but using OOOR, so XML/RPC calls under the hood.
  I checked, the XML/RPC call was really OK

  What happened is that sometimes, the write {'state': 'draft'} wasn't actually performed in the database!!
  I could then check reading the record using OOOR or directly in the ERP via GTK (+refresh of course), pickings or orders where still confirmed.

  This was totally inconsistent. Running the exact same code again,
  would go a little further and process some more orders.

  Also, something that also proved my OOOR code was right is that by
  just introducing a sleep(0.5 secs) before the write call, suddenly I
  had no more error at all!

  Also, by running the server in log-level=debug_rpc, I could check that the server really received the 'write' call properly.
  It was even answering True to the call, but not writing it in the database as expected.

  This might never have been in production before because GTK or
  webclients manual manipulations will wait a bit before sending more
  write calls.

  Also, OOOR trunk RSpec test suite fails in some ways that I found
  inconsistent with v6 (redoing the same operation that failed worked
  later). On the contrary OOOR 1.4.2 had always no failure with OpenERP
  V5. Unfortunately I had no time to investigate it further.

  
  Yesterday I tried to made a loop that call write on the name partner field using XML/PRC from Python on a localhost and write a different value each time. Then I was doing a read to check the value was the one I wrote. It was working always both from Python or OOOR. So so far I wasn't able to reproduce the problem simply.
  May be it's linked to the object/field I was writing, may be it's linked to the fact the host is remote. Or may be it's even an OOOR trunk bug though I stringly doubt about that as log-level=debug_rpc proved me the proper calls where received by the server.

  
  This is definitely worth a double check.
  Can anyone confirm this issue?