Week 5 & 6

I'm now at my 6th week at Docbyte for my internship. My next task was to check for performance errors and potential bottlenecks in EPA. To avoid premature optimization I've used Visual VM. It's a monitoring tool for Java applications. You don't have to add anything to your code to use it. Visual VM automatically checks all running Java application on your device and also has the possibility to monitor Java-apps on remote devices.
After running a version of EPA locally, I've started to monitor the CPU usage at between several points in the application. The thing I noticed was that most of the CPU time was spent on MySQL. Something made it run terribly slow. I've heard Michiel say that it was running a lot faster using sqlserver instead of mysql. After switching my local version to sqlserver and monitoring the same processes again, it was clear that this was a lot better.

Afterwards, most of the CPU usage happened in the Documentum classes, the file repository of EPA. When I switched to the null-repository I've made earlier, I noticed that it the performance increased a lot, which is actually 'stating the obvious' because there are no files to be loaded into EPA. Last but not least, I've reduced the CPU time on the garbage collector a bit by making sure that no new objects were created in loops.

Since the new XDS-repository was still being created by one of the other interns, I've couldn't continue to make noticeable performance changes in EPA.
New tasks of the DocShifter project were assigned to me: 'Automate building and packing in Jenkins' & 'Optimize Installer'. Let me first tell you about Jenkins. Jenkins is an open source continuous integration tool written in Java. It automatically builds your project. In our case it builds the docShifter projects on Stash. (Stash is the on-premises Git repository management solution for enterprise teams. It allows everyone in your organisation to easily collaborate on your Git repositories.) If Jenkins is asked to build one of the docShifter projects (receiver, beans, sender, ...), it will first check if there are changes in the version on the Stash. If the stash contains changes, Jenkins will clone the project first and afterwards start the building using Ant. Once this is done, it saves the files that were built and triggers the installer to be built. The installer uses the saved files of the other DocShifter projects to create an up-to-date installer. If the build of the installer is done, the installers (32 & 64bit) are stored in Jenkins and are ready to be used.

Once this was done, it was quite easy to create an automatic updater for DocShifter. But there was one problem. The installer and updater are created with IzPack to make sure we have a wizard-like installer. The problem was that IzPack has a couple of boudries. In this case, it can only run batch files at one point during the installation. To update docShifter, I had to stop the services from running, install the new files and start the services again. I had to make a choice between stopping them first OR starting them after the update. For now, I chose to stop the services first. Perhaps I can still change this and hopefully make it work properly. I still have to add the print service (that one of the other interns fixed) to the installer with Jenkins, but it should be just the same way as adding the receiver or sender so this shouldn't cause any problems