Managing Zing by Systems Engineers
What do you like best?
Zing comes in two parts; the Zing Virtual Machine, (ZVM, which is a Java Virtual Machine) and Zing Service Tools (ZST) which is software installed on Linux along with their kernel module that does memory management. As a Systems Engineer I find managing Zing in an enterprise environment very easy.
Upgrading is simple. A ZST upgrade is not needed for every ZVM upgrade - multiple versions of the ZVM can run on the same ZST. ZSTs are packaged in RPMs, so all we do is "yum update" and "reboot".
Planning/Sizing for Zing on hardware is a little different, but still straight forward. When the zing kernel module starts it immediately takes a chunk of RAM, an all ZVM memory allocation is done inside there. There is no risk of other operating system processes depriving Zing Java of heap space, as it's already taken by the kernel module.
Licensing can either be done by a centralised server for all ZVMs to "dial home" to, or a static license file can be stored on the servers.
What do you dislike?
Early versions (years ago) of ZST didn't upgrade cleanly, we often had to double check that kernel modules were removed from the module tree correctly. However the more recent versions do not have this problem and our management of ZST is a lot smoother now.
Recommendations to others considering the product:
Highly recommended for people interested in high performance Java applications.
What problems are you solving with the product? What benefits have you realized?
We use Zing as the JVM underneath our low latency trading platform. It's memory management prevents a number of the normal Java GC related problems. It doesn't remove the issue entirely (Zing still has to pause to get a consistent state) but this is few and far between.
