Re: [Wrapper-user] What is the best way to handle JRE updates on end user computers

[Leif M. <lei...@ta...>]

Stephen,
Your workarounds sound like good solutions.   We are discussing this again
internally.  But are not yet sure of a good way to handle this.   I will
let you know if we figure something out.

Cheers,
Leif


On Wed, Jul 2, 2014 at 1:21 AM, Stephen Slater <s.s...@ca...>
wrote:

> Leif,
>
>
>
> Thanks for your response.
>
>
>
> Having the wrapper shut the java server down during a JRE update then
> restart again when finished would be a good solution for us.
>
>
>
> Our particular software tends to be used by one or a very small number of
> users.  While the client applet can be launched from any computer that can
> see the server, it seems to be common that they run the client and server
> on the same computer.  What is happening is that customers are upgrading
> their JRE when a new version comes out and it is failing because the server
> is using it.  They then phone us up saying they have upgraded Java and now
> the software doesn’t work.  So at the most basic, we need a change such
> that if Java gets updated it does not break the system.
>
>
>
> I have discussed options with colleagues and what we are thinking of doing
> unless someone suggests anything better quickly is (a) Switch to installing
> our server with its own private copy of the JRE so it won’t block upgrading
> the main copy.  (b) Add an option to our client software to update the
> server’s private copy of JRE from the main one (which would be user
> initiated at a time to suit them).  This would be done by client applet
> telling server to do the update.  Server would set off a new process on the
> main copy of JRE.  This would close down the wrapper, replace the private
> copy of JRE with the main one, then restart the wrapper again.
>
>
>
> Regards,
>
>
>
> Stephen
>
>
>
>
>
> *From:* Leif Mortenson [mailto:lei...@ta...]
> *Sent:* 01 July 2014 02:36
> *To:* Wrapper User List
> *Subject:* Re: [Wrapper-user] What is the best way to handle JRE updates
> on end user computers
>
>
>
> Stephen,
>
> Currently the Wrapper does not directly support this.
>
> What is the behavior that you are hoping to see?
>
> If a new JVM version is released, it will get downloaded and can be set to
> run the installer automatically.
> But when that happens, are you hoping that the Wrapper will shutdown the
> JVM during the installer and then relaunch it?
>
> I have looked into this before, but have not yet figured out a reliable
> way to detect if the installer is running efficiently.  There are some
> calls to detect when Windows is in the progress of installing something but
> at that point it would already have started in the install and an error
> would have been thrown by the installer.
>
> Once we have been able to detect that an installer is running, we would
> have to decide if that installer even has anything to do with the JVM or
> application being run by the Wrapper.  Stopping the JVM for any and all
> installers would cause its own set of problems.
>
>
>
> Even if we got this to work, it would need to be optional as auto upgrades
> on any 24x7 server are risky.
> 1) There is no guarantee that the new Java version will work correctly
> with the application.
>
> 2) The timing of the JVM getting stopped and restarted would be controlled
> by when the installer ran, this could cause problems for users of the
> application if it was restarted at a strange time.
>
> We have also been thinking about ways to allow application upgrades and
> even Wrapper upgrades as well.  These also quickly have the same issues.
> It appears to be possible for an installer to detect if some of the files
> that it wants to install are in use, but not so much for the target
> application to detect if it or its components are about to be reinstalled.
> That appears to be why installers ask you to shutdown the target
> application or forcibly do it themselves.
>
> Anything would of course need to be configurable so it could be disabled
> for users that didn't want to use it.
>
>
>
> I'd appreciate any thoughts or suggestions anyone has on these issues.
>
> Cheers,
> Leif
>
>
>
> On Tue, Jul 1, 2014 at 2:22 AM, Paul Gale <pau...@gm...> wrote:
>
> >We have considered including a separate version of JRE used only by our
> service when our software is installed, so that the main JRE installation
> used by browsers could be updated without the wrapper service interfering,
> but our management considers this not acceptable because it would not get
> updated with the latest JRE security fixes.
>
> Bundling the JRE is definitely gets my vote. If you made your application
> auto-updating then that would handle the ability for your customers to
> obtain timely security fixes.
>
> Any other kind of solution is ultimately a hack with all sorts of problems
> that can arise not the least of which is that customers can install a JRE
> that your application may not be compatible with. We had a similar
> situation where users were upgrading JREs galore (which is not always what
> you want) causing all manner of problems. Bundling the JRE would have fixed
> that but we ended up switching to a web based application instead. Life has
> been a lot easier since.
>
>
>
> On Mon, Jun 30, 2014 at 6:50 AM, Stephen Slater <s.s...@ca...>
> wrote:
>
> (Re-submitted after subscribing to the mailing list)
>
>
>
> What is the best way to handle JRE updates on end user computers once a
> service is up and running using the wrapper?
>
>
>
> When a new JRE update comes out, on running the installer, it notes that
> “java.exe” is running and asks to stop this so that it can update java.  If
> I tell it to do this, the wrapper log shows “JVM exited unexpectedly” and
> that it then automatically restarts it.  The JRE update install then seems
> to complete OK but has actually failed with browser plugins not added.
> Restarting the computer does not fix this, and it is necessary to uninstall
> the JRE and install it again to fix it.  Until this is done Java client
> applets run on the same computer are broken.
>
>
>
> If I manually stop the service while doing the JRE update then everything
> goes fine, but if the software is installed on a customer’s computer it
> would be highly preferable for automatic Java updates to go through without
> them having to worry about stopping a service.
>
>
>
> We have considered including a separate version of JRE used only by our
> service when our software is installed, so that the main JRE installation
> used by browsers could be updated without the wrapper service interfering,
> but our management considers this not acceptable because it would not get
> updated with the latest JRE security fixes.  We also considered using the
> wrapper.restart.delay setting to delay restarts by 15 minutes to give the
> JRE updater time to finish, but our management also declared this
> unacceptable.
>
>
>
> What is the best way to deal with this?
>
>
>
> (We’re running version 3.2.3 by the way.)
>
>
>
>