office restart service

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

office restart service

stephan.bergmann
I see the following problem with the implementation of
<http://qa.openoffice.org/issues/show_bug.cgi?id=108704> "Need UNO
service for restarting the office process" in combination with its use
in the implementation of
<http://qa.openoffice.org/issues/show_bug.cgi?id=77196> "Bundled
extensions":

108704 makes available a service that shuts down the running soffice
process and restarts it with the same command line arguments it was
originally started with.  (At least, that is my understanding from
glancing at the code.)

77196 wants to make use of that service to decide, during soffice start,
whether changes to bundled extensions require an immediate soffice restart.

A starting soffice opens two kinds of connection acceptors.  For one, it
starts an inter-office "IPC" connection
(desktop/source/app/officeipcthread.cxx), used to make sure that only
one soffice process is ever running for a given user at a given point in
time (presumably to avoid chaos in the UserInstallation), and
additionally started soffice processes for that user connect to the
initial process and pass their command line arguments to the initial
process, which then handles them.  For another, it starts URP connection
endpoints for all the "-accept" arguments passed in on the command line.

It is important in which order the three events (77196-restart,
accepting "IPC", and accepting "-accept") happen during startup.

Accepting "-accept" should come after 77196-restart (otherwise, there
would be the problem of an external process connecting to the first
soffice instance, only to immediately afterwards loose its connection
again when soffice restarts).  This is the easy part.

The problem is with the ordering of accepting "IPC" and 77196-restart.

If accepting "IPC" happens before 77196-restart, a second soffice
process can pass its command line arguments to the first instance of the
first, accepting soffice process, which then restarts and thus forgets
about the command line arguments from the second process.  The net
effect for the user is that his second soffice invocation (requesting to
open a specific document, or to accept on a specific UNO endpoint)
appears to have no effect.

If accepting "IPC" happens after 77196-restart, this enlarges the time
span in which multiple soffice processes for a single user can run
concurrently, potentially causing chaos in the UserInstallation.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: office restart service

Mikhail Voytenko
Hi Stephan,

indeed we have a problem to transport the adjusted command line
arguments to the starting script/executable. Till now the problem has
affected the crash-recovery restart only, since it was the only scenario
that has triggered the office restart. The problem is solvable, but it
was not recognized as important enough to get attention, there are
enough problems that are much more important.

I am currently not sure, what exactly is done for the Bundled extensions
before restart, but I suspect that the configuration is accessed. That
means that the IPC-thread must already run at this point.
If my understanding is correct, I must confess, that I do not see an
atomic solution for the problem currently. The current behavior (
IPC-thread starts before the restart ) looks for me as the lesser evil,
since the probability of the scenario is very small ( I am in doubt that
we ever get it without writing a special script for this ), and even if
it happens, it still prevents the concurrent access to the configuration.
If I misunderstand something and there is a better solution, I would of
course support it.

Best regards,
Mikhail.

PS: As far as I understand, if IPC-thread starts and creates pipe after
accessing the configuration, it will not enlarge the dangerous time
span, it will create it, since currently the IPC-thread is started at
the very beginning, before the configuration is accessed.

On 05/12/10 16:54, Stephan Bergmann wrote:

> I see the following problem with the implementation of
> <http://qa.openoffice.org/issues/show_bug.cgi?id=108704> "Need UNO
> service for restarting the office process" in combination with its use
> in the implementation of
> <http://qa.openoffice.org/issues/show_bug.cgi?id=77196> "Bundled
> extensions":
>
> 108704 makes available a service that shuts down the running soffice
> process and restarts it with the same command line arguments it was
> originally started with.  (At least, that is my understanding from
> glancing at the code.)
>
> 77196 wants to make use of that service to decide, during soffice
> start, whether changes to bundled extensions require an immediate
> soffice restart.
>
> A starting soffice opens two kinds of connection acceptors.  For one,
> it starts an inter-office "IPC" connection
> (desktop/source/app/officeipcthread.cxx), used to make sure that only
> one soffice process is ever running for a given user at a given point
> in time (presumably to avoid chaos in the UserInstallation), and
> additionally started soffice processes for that user connect to the
> initial process and pass their command line arguments to the initial
> process, which then handles them.  For another, it starts URP
> connection endpoints for all the "-accept" arguments passed in on the
> command line.
>
> It is important in which order the three events (77196-restart,
> accepting "IPC", and accepting "-accept") happen during startup.
>
> Accepting "-accept" should come after 77196-restart (otherwise, there
> would be the problem of an external process connecting to the first
> soffice instance, only to immediately afterwards loose its connection
> again when soffice restarts).  This is the easy part.
>
> The problem is with the ordering of accepting "IPC" and 77196-restart.
>
> If accepting "IPC" happens before 77196-restart, a second soffice
> process can pass its command line arguments to the first instance of
> the first, accepting soffice process, which then restarts and thus
> forgets about the command line arguments from the second process.  The
> net effect for the user is that his second soffice invocation
> (requesting to open a specific document, or to accept on a specific
> UNO endpoint) appears to have no effect.
>
> If accepting "IPC" happens after 77196-restart, this enlarges the time
> span in which multiple soffice processes for a single user can run
> concurrently, potentially causing chaos in the UserInstallation.
>
> -Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: office restart service

stephan.bergmann
On 05/17/10 09:31, Mikhail Voytenko wrote:
> The current behavior ( IPC-thread starts before the restart ) looks
> for me as the lesser evil, since the probability of the scenario is
> very small ( I am in doubt that we ever get it without writing a
> special script for this ), and even if it happens, it still prevents
> the concurrent access to the configuration.

I think so, too.  Just wanted to have this discussed explicitly somewhere.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]