Interesting thought, and thanks for the feedback. It's worth taking a closer
look at how MyClient is designed to make sure we didn't miss something that's
causing this problem.
Our service is designed similarly to how you describe. MyClient is a control
process/thread that is an object containing an org.quartz.Scheduler, which
executes Jobs (which I believe are fundamentally threads) to perform tasks.
MyClient also has a stop() method which, when the service is asked to stop, the
Java Service Launcher passes the stop request by calling MyClient's stop()
method. This method calls Scheduler.shutdown(), which tells the executing Jobs
to stop and unloads any resources used by the Scheduler.
I also know that the developer has actively tried to avoid/prevent the MyClient
service from waiting for the bundle exe to terminate using this:
Runtime.getRuntime().exec("cmd /c start /I /B " + installerFilePath + " -quiet
-norestart -l*v " + installerFilePath + ".log");
return;
Runtime.exec() returns a Process object on which we, if desired, could call
.waitFor() to stop execution until the Process terminates. However, we don’t
call Process.waitFor(), because we of course do not want to wait for the bundle
exe to terminate, but instead want the Job to complete execution and terminate
itself. And as you can see, we return immediately, which ends the Jobs
execution.
Thus, I don't think we're doing anything in MyClient that should wait for the
bundle exe to finish. Furthermore, I'm not sure the problem is as simple as
that, since our problem is *not* that our installer/bundle is hanging, waiting
for the MyClient service to stop when it never does. The problem is that the
package's Restart Manager is requesting a restart because completing the
uninstall, because it thinks that "itself" (implying the bundle) is holding
files in use that it needs to change, but it doesn't seem to realise that the
bundle exe was executed from the Service, which it does knows will be shut
down. I think it's just somehow unable to link the service (that is using file,
but can and will be stopped) to the executing bundle. There may also be some
complicated interactions between Java's spawning of processes and the Windows
service infrastructure, since neither of them were ever originally intended to
be used together.
Fortunately, we have been able to consistently update MyClient from an external
process, so we are currently splitting the updating functionality into a
separate service, which should be able to shut down the services and run the
installer to update the software from a dedicated updater. At least, that's the
plan. Here's hoping it works, because I've been banging on this problem for too
long!
That said, if you or anyone has any other ideas or thoughts, please do fire
away. I much prefer simpler solutions over more complicated ones, like having a
separate dedicated updater (that now I need to worry about how to upgrade the
updater, if need be :-P). So any more ideas are definitely very appreciated.
Alain
-----Original Message-----
From: Phill Hogland [mailto:[email protected]]
Sent: July 4, 2013 11:27
To: [email protected]
Subject: Re: [WiX-users] Upgrade uninstall restart issue
As Rob indicated the dependency "loop" would not exist by default. It depends
on how the designer implemented the MyClient service. A Windows Service should
have a control handler thread that processes events from the Service Control
Manager and separate worker thread(s) that implement the functionality of the
service (such as calling CreateProcess to launch another application). The
control thread must always run and process events from the SCM. If it becomes
blocked the SCM will report an error against the service for not responding.
If the SERVICE_CONTROL_STOP action cannot be implemented immediately the
service should respond by setting the service's status to SERVICE_STOP_PENDING
and incrementing the HintCounter to avoid a SCM timeout.
Your theory would suggest that in addition to the worker thread calling
CreateProcess to spawn the bundle (and then the bundle calling CreateProcess to
spawn the package) the developer of the MyClient service implemented some code
to wait for the bundle exe to terminate before it "allowed" the control handler
thread to process an SCM event. (Not generally advisable, but maybe there is a
good reason.) So your theory requires that a designer implement this behavior
in the MyClient service. Your theory also assumes that the bundle exe has code
to determine when the package has terminated, which I believe is correct. So
that part of the loop is probably valid. The question however goes back to how
the MyClient service is designed.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-uninstall-restart-issue-tp7586315p7587151.html
Sent from the wix-users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
