Docs won't open while soffice running as service

[grinder22]

I've written custom reporting software that runs as a Windows service. My windows service connects to OpenOffice through the CLI.

If I have a Writer document open on my desktop, the CLI call to the bootstrapper in the service always blocks. It basically locks up and doesn't recover.

Code: Select all   Expand viewCollapse view

_context = uno.util.Bootstrap.bootstrap();

To try to solve this I figured out how to launch soffice as a service with the following command. But when I run this service I can't open any documents.

Code: Select all   Expand viewCollapse view

start soffice -headless -accept=pipe,name=pipe_name;urp -noffirststartwizard

Is there any way to configure this such that I can run my headless soffice service so it can interop with my windows service, and still be able to open and edit documents without any conflicts?

Interestingly it works as expected when that original call to boostrap() is not from the Windows service. When I test my code directly without starting as a service I can work with multiple documents and the service will still bootstrap and create documents as well, with no conflicts.

[John_Ha]

This may be worth investigating.

If you are running, say, Writer, there are two processes running - soffice.bin (which seems to handle I/O) and soffice.exe (swriter.exe?). If, due to an error when shutting Writer, soffice.exe stops but soffice.bin remains then, when you next try to start Writer, you merely silently create a new soffice.bin process and nothing else happens. It appears to the user that Writer does not start.

Search the Writer forum with soffice.bin for more.

[grinder22]

If I open Writer, I can see the two processes (bin and exe). If I run my report engine locally I can see the new process blip open and quickly exit again. If you weren't watching for it you would never see it. The report generates fine.

If I don't have anything open, then the process stays open until I kill it in code. I can see all the command arguments in the task manager. The bootstrapper is basically firing up a named pipe instance if you use the default method.

If I run my report engine from a service the behavior is different, that's when it locks instead of blipping open and closed. If I try to start an open office service by hand I get the same behavior. If the service instance starts first (by hand or by the bootstrapper) then manually opening writer blocks.