| Summary: | Concurrent --convert-to pdf sessions fail silently | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Neil Youngman <neil.youngman> |
| Component: | Writer | Assignee: | Mike Kaganski <mikekaganski> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 6.1.2.1 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | target:6.3.0 | ||
| Crash report or crash signature: | Regression By: | ||
|
Description
Neil Youngman
2018-10-18 13:05:44 UTC
This is not a bug per se: the first started instance grabs the profile, which causes all subsequent instances (launched during the first session run) to try to connect to the first session and ask it to process their request. But the first instance is launched with a single --convert-to parameter, so it doesn't process others' requests, but just finishes its job and quits. A workaround could be to launch the worker instance in advance, without any --convert-to switches, so that it would run in the background and wait for other instances' requests. Then it would work. This has an additional benefit of greater performance (no overhead of initializing LO for every launched process). Another way would be to guarantee that the first instance is finished before launching the next (no concurrent runs). But of course, this is a valid enhancement request, to allow signalling to secondary instances that their request is refused so that they could wait until the primary instance is finished, and do that themselves (with the risk of waiting indefinitely for the primary instance in case it hangs for some unrelated reason, then behaving similarly to bug 38915). Saying that a failure to perform a requested function is not a bug seems to be taking "it's a feature not a bug" jokes a little too far. It seems to be an unintended consequence of other design decisions and, at the very least, it's a violation of the principle of least surprise. As someone who is not familiar with the architecture of LibreOffice, it's not obvious that if I request a standalone conversion that it would/should connect to a prior instance and ask that to perform the operation. Similarly I would not necessarily expect such a job to perform operations for other instances and continue running until there are no more client instances expecting it to run jobs for them. As a practical solution for my immediate needs I believe the workaround I have will allow me to run independent jobs in parallel. Conceptually it seems to me that the headless option needs to be split into 2 different options, a headless server and a standalone one-shot operation. https://gerrit.libreoffice.org/65610 The proposed change would allow to detect failures by checking the process exit code (currently it returns 0, as if everything went fine). Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b1491ff14a22639775dd8b8ca130258a1b95421b%5E%21 tdf#120676: don't send "processing done" when refused to process It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. I installed a daily build from libreoffice-6-2~2019-01-01_21.34.24_LibreOfficeDev_6.2.0.1.0_Linux_x86-64_deb.tar.gz and I can see no difference. (In reply to Neil Youngman from comment #5) > I installed a daily build from > libreoffice-6-2~2019-01-01_21.34.24_LibreOfficeDev_6.2.0.1.0_Linux_x86- > 64_deb.tar.gz and I can see no difference. I've found the right daily build now and it seems to wait until the first conversion finishes before starting the second. |