Bratty Redhead

the sarcasm is free!

My Favorite JVM Arg EVER

This is partially a post for posterity because I can never remember the format of this when I want it and I have to search all over the Internets for it.  And for some reason, it’s really hard to find with keywords.  Possibly my google-fu sucks, but I actually think it’s a java developer conspiracy.

The first time I found this jvm arg, it was by accident.  I was reading a page of comprehensive JVM args.  No it wasn’t for fun, although I was enjoying it.  I was on a gig to help a client get rid of 20 second garbage collections that were crashing their site.  So I was reading through the page just to see what might be useful and I found this:

-XX:MaxJavaStackTraceDepth=<num>

It was love at first sight.  See, I know developers lurve their stack traces and exceptions.  Truly.  But I’ve met some truly horrendous apps.  You know the kind.  They throw 500 line stack traces every time someone types in a bad password. Or you have an overrun team that, once an app is in production, they don’t have time to tune the app and so you are stuck with 2000 lines of stack trace for every exception, even though it only takes < 10 to figure out where to look for trouble.

After I found this and used it, I had bookmarked the page of wonderful jvm options, but it was dead the next time I went there. So I ended up searching the internet for it later and found that my googling led me all over.  I found a stackoverflow discussion where a harried admin was asking about it and a herd of VERY ANGRY developers jumped all over him saying things like

“How dare you truncate our wonderful stack traces!”, and

“An exception is called that because it’s exceptional. There’s a reason for it and you shouldn’t truncate it!” 

Oh they were like an angry mob.

But I have to tell you, this arg is an admin’s best friend if you have apps in your care that can’t be bothered with proper tuning on the dev side.  Often this was because a client had a contract dev team come in, deliver an app and then leave.  There was no one to fix it.

There’s no shame in cleaning up your log files so they are readable.  It’s tough to actually dig into a problem if you have thousands of lines of “benign” errors filling your world.  This option allows you to limit the damage done by excessive logging while still seeing that an exception is being generated. Of course, with all the wonderful logging packages and tools with filters out there today, this sort of thing is less important if you are filtering, but there are lots of admins out there with nothing but the CLI, syslog and vi even today. This post is dedicated to them.