Server CPU goes to 100% Printing Invoices, Times Out

[paulkoan]

Printing a one-line non-product invoice.

Select Print->Invoices, and Click "Ok". The Ok button will stay depressed for about three minutes, and then a "Print took too long, timed out" message is displayed. This was tried with and without a company logo.

On the server, the CPU goes to 100% for the openerp-server python process. It remains at 100% until restarted.

The client is rev 917
Server is 1686
Addons is 2195

Python on client and server is 2.5.2, and pypdf is 1.12. Using the net-rpc protocol. I have /home/terp/filestore defined as filestore in .openerp_serverrc and it is writable by the user running the server. Nothing appears in this folder.

I have debug logging on both the client and server, and nothing is printed during this process, which makes it hard to help diagnose.

Please let me know what I can do to provide enough information to help isolate the cause.

Kind regards,

Paul

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello, I dont get such error.

"Printing a one-line non-product invoice" >> encoded as: i created invoice line, with description(but no product).

[paulkoan (c-launchpad-airbred-com)]

Is this "incomplete" because I need to provide more information (if so let me know what), or is it incomplete because more than one person needs to have the problem before any advice toward solving it can be given?

At this late stage in the 5.0 development, I imagine most of the bugs being reported would be difficult to reproduce because of the limited number of environments they are being tested in. Would it be worth providing some troubleshooting tips, particularly where the bug is as impactful as taking 100% of cpu?

We all want the 5.0 release to be a success.

Thanks,

Paul

[Jay Vora (Serpent Consulting Services) (jayvora)]

Dear, I actually dont see any reason that it can happen,so may be its not complete details enough or not completely tested by us.

I am making other people test, they are also not getting it.

So , now I am making it as invalid.

I request you to please recheck it.

[paulkoan (c-launchpad-airbred-com)]

Hello Jay,

Ok, I figured out the problem. If the document management filestore is not writable when you first try to print an invoice, you will get a traceback error - write permission denied.

However, the ir_attachment entry is still created, even though a file isn't created in the filestore.

If you fix the filestore so that it is writeable, and go to reprint the invoice, ir.attachment returns zero data to report_sxw.py - because the file is not there, which then passes zero data to Pdffilereader in pyPdf. This then hangs because it cannot handle a zero length pdf stream.

I think the answer is to not commit the entry to ir_attachment until the file is written. But more importantly, if the filestore gets deleted, ir.attachment should recognise this and signal that the attachment doesn't exist, rather than returning an empty stream.

By the way, as per bug 320126 I have tried:

[option]
filestore=/home/oerp/filestore

But this is not recognised as far as I can tell, it still uses the default ./filestore.

[options]
filestore=/home/oerp/filestore

Did not work either.

[Fabien (Open ERP) (fp-tinyerp)]

set the filestore as writable, we can improve aftert v5 if you create a blueprint.

[paulkoan (c-launchpad-airbred-com)]

The filestore being writeable isn't the issue. There are any number of reasons why a file that ir.attachment expects to be there won't be there. At the heart of the problem is that the ir.attachment gets data from a source external to openerp-server and doesn't check it is valid.

It would be acceptable for this to happen if it just returned an error, but it doesn't - pyPdf will take 100% of the server CPU. In a production environment this would represent openerp in an extremely bad light.

I suggest this simple "fix":

After:

  d = base64.decodestring(pool.get('ir.attachment').browse(cr, uid, aids[0]).datas)

add

  if !d:
    raise FileError, "Attachment not found"

This will at least trigger a traceback and not kill the entire server.

[paulkoan (c-launchpad-airbred-com)]

I have changed this to "new" from "invalid" because I am not sure if you guys read the comments added to invalid bugs. If this isn't the right way to do this, please let me know.

[Fabien (Open ERP) (fp-tinyerp)]

please create a blueprint for fix in next releases.