Hi Vincent,

Am 21.10.2013 10:18, schrieb Vincent (CloudSuite):
Hi,

I am curious to your experience with unoconv (a module part of OpenOffice / LibreOffice and
used in Tryton to convert ODT files to PDF or other formats).

We use LibreOffice 3.6, IIRC mainly because OpenOffice had Java dependencies that we did not want to install.
We are also still on Tryton 2.4.

On one of our production servers we have a lot of stability issues.
Unoconv crashes several times a month and all we can do is kill the running soffice.bin and unoconv processes and restart the unoconv deamon. And then hope it will not happen again soon. When it does, the customer has to kill the client process to restart.

On our development server it's quite stable. But on this machine unoconv is idle most of the time. On the production server it is much more busy, as I think about all of the customer's documents are in PDF format.

Tryton 2.4 originally uses pipes, but we had even more stability problems with this. So I changed it to sockets:
unoconv = socket,name=trytond;urp;StarOffice.ComponentContext

And this is how I start the deamon:
/opt/libreoffice3.6/program/soffice --display :0.0 --norestore --headless --accept="socket,host=localhost,port=2002;urp;StarOffice.ComponentContext" For us this improved stability a lot, but it's still not good enough. Anyone willing to share their experience with unoconv on a busy server?

We also had some unoconv crashes on both, production and development server. Repeating the task from GUI always resolved the issue. Because of that we put the loop into the source code like this:

        try:
            errcnt = 0
            while True:
                proc = subprocess.Popen(cmd, stdout=subprocess.PIPE)
                stdoutdata, stderrdata = proc.communicate()
                if proc.wait() != 0:
                    if errcnt < 5:
                        errcnt += 1
                        continue
                    else:
                        raise Exception(stderrdata)
                return stdoutdata
        finally:
            os.remove(path)

in report.py and since 4 months we had no more problems.
Just one more thing: Ususally there is just one person creating reports on the server and it is not *really* busy.

Regards,
Vincent

Hope it helps

Ralf

Reply via email to