How it works now
The dieing process lunches the restart.shIn this time two instances of tomcat run on the same resources
After the old process died the new one should be upThis is highly OS dependent and can cause race conditions and configurations dependent process behaviour.
Concepts
WAR redeployment
Just redeploying the WAR application on Tomcat. This would be an ideal solution but was previously tested i shown the following faults:
- Tomcat generally crushes after 3-6 hot redeploys
- this may be due to some configuration options
- exploded WAR's have many problems, maybe configuring Tomcat to not explode the WAR is an solution
- qcadoo MES may have memory leaks on startup and shutdown
- by default garbage collection does not sweep old unused class bitcode
Issue: http://issues.qcadoo.org/browse/QCADOOMES-117
We should retest with Tomcat 7. It is tolled that it solves many memory leak problems. Plus it has a very nice feature called Parallel Deployments which could use as a fall-back mechanism when some one creates a wrong plugin. We should test how multiple deployments of qcadoo MES affect memory usage.
Useful links:
- http://www.javacodegeeks.com/2011/06/zero-downtime-deployment-and-rollback.html
- http://java.dzone.com/articles/memory-leak-protection-tomcat
- http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
Monitor process
Create a process which monitors the tomcat process. When a restart is requested the monitor firstly shuts down one process and then starts the new one.
We separate the binary distribution in to two directories:
- mes-application - in this catalog we put all the files that ware in the old binary distribution
- qcadoo-monitor - here we create a minimal tomcat distribution the monitoring web application