What is the best way to handle JRE updates on end user computers

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

What is the best way to handle JRE updates on end user computers

Stephen Slater

(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.)


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Reply | Threaded
Open this post in threaded view
|

Re: What is the best way to handle JRE updates on end user computers

Paul Gale
>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 <[hidden email]> 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.)


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Reply | Threaded
Open this post in threaded view
|

Re: What is the best way to handle JRE updates on end user computers

Leif Mortenson-3
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 <[hidden email]> 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 <[hidden email]> 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.)



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Reply | Threaded
Open this post in threaded view
|

Re: What is the best way to handle JRE updates on end user computers

Stephen Slater

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:[hidden email]]
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 <[hidden email]> 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 <[hidden email]> 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.)

 


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user
Reply | Threaded
Open this post in threaded view
|

Re: What is the best way to handle JRE updates on end user computers

Leif Mortenson-3
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 <[hidden email]> 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:[hidden email]]
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 <[hidden email]> 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 <[hidden email]> 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.)

 



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Wrapper-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wrapper-user