Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

News June 2011

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Back to newsletter 127 contents

The tale from about tape backup still being important (see this month's listed news items below) reminds me of how I first learned the lesson that you need some kind of data storage which allows you to restore data from periodic backups. It was sometime in the 1990s, and a major exchange trading system went down and was unavailable for several hours. I recall an insider telling me why it took so long to get back online even though it had a live failover capability.

A note from this newsletter's sponsor

Free Java Performance Tool - From AppDynamics
Fight fires in production with less than 2% overhead.
Gain complete visibility into your java app. Free Download!

The system went down when corrupt data was detected - in an exchange system any corrupt data is hugely serious, since who knows what trades that might affect and how! At that point, the operators could have failed over after only a short outage. But the problem is - if the system has corrupt data, how do you know that is not systemic, and that the failover system isn't going to cause or use the same corruption? Without knowing what caused the corrupt data, failing over was extremely dangerous. While the failover system could be quickly analysed for integrity to see it didn't have the corrupt data, if the problem causing the corruption was part of the system then kicking off the failover would just result in another corrupt system, but with this time no possibility of failing over to a 'good' system.

So before failing over, the operators had to determine the cause of the corruption, and then evaluate their options. As it happened in this case, the primary disks had been corrupted and this was isolated so the failover was safe. The details always stuck in my mind as a cautionary tale - having failover capability is not enough, having a live backup is not enough (that could have been corrupted before it was noticed); you need access to older data so that you can recover from your own system causing corruption.

Now on with this month's newsletter and all our usual Java performance tools, news, and article links. We also have a new cartoon over at evolve your performance over time using industry best practices, and, as usual, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.


Java performance tuning related news.


Java performance tuning related tools.

A note from this newsletter's sponsor

New Relic RPM - The Revolution in Java Performance Management is Here!
Affordable SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin


Jack Shirazi

Back to newsletter 127 contents

Last Updated: 2022-06-29
Copyright © 2000-2022 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us