JVM Boolean Options

While trying to generate a a Java Heap Dump, I remembered there is one JVM option I could use for this purpose. Since I can’t always remember these options’ names, I went to the Oracle documentation.

So I could extract the following arguments:

-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/jvm/dumps/

After limiting my Java Heap size to a value that I know it’s too low, I was expecting the Heap Dump to be generated whenever I got an OutOfMemoryError. But no dump got generated. I googled the issue, checked for JMV bugs but the only reported issue was a miss-usage when you give the JVM options after the Java Main class, but that wasn’t my case.

Then I stumbled on a slightly different version of my original setting (the one that I copy-pasted from the Oracle site):

-XX:+HeapDumpOnOutOfMemoryError

Then, I remember I once read about Boolean JVM options, and the very same Oracle site details this usage:

“Boolean options are turned on with -XX:+ and turned off with -XX:-.”

I think the Oracle JVM options table should show the “+” version, since that’s usually what you are looking for, especially because it’s disabled by default (so the “-” version behaves like not giving it at all).

N.B.

The HeapDumpPath should point to a folder, but if your setting is something like /logs/jvm/dumps/, and your OS only contains /logs/jvm, then you won’t get a “java_pid.hprof” file within the /logs/jvm/dumps/ folder, but a dump file in /logs/jvm/, as the JVM doesn’t create the missing folders (a.k.a mkdirs).

Enter your email address to follow this blog and receive notifications of new posts by email.

Advertisements

Teaching is the best way to learn

Software development is all about knowledge, and nowadays the amount of things a programmer needs to know skyrocketed. Most of the time developers are hired by matching their current skills with some project requirements. The project eventually ends, and the developer is assigned to a new project, sometimes using different technologies than what he was previously hired for. What’s the policy for training this guy to deliver his best the soonest possible?

Usually training and coaching are left-out, so each programmer is on his own. Every time we leave things to chance a huge risk is implicitly undertaken. I believe we should give more to training and coaching and see them more of an investment rather than a spending.

Continue reading “Teaching is the best way to learn”

Why I never blame open source projects

Every now and then I get to read someone’s bad thought towards a given open-source framework. When I started programming Struts web framework was at its prime, everybody loved it. But then, little by little people started blaming it and then hate followed.

Then people started blaming Hibernate and recently MongoDB. I’ve even read that “I shouldn’t use MongoDB“. Well, I delivered projects on Struts, Hibernate and MongoDB, and none of those was ever a blocker.

If there is someone to blame it’s usually us, not the frameworks we use. If you download and browse the source code of a given open-source project, you’ll be pleasantly surprised by the quality of code. Most of the time I find it at least as good as I’d do it myself. Many open-source projects are the result of endless hard-working hours of many passionate developers, so why should we blame their frameworks then?

Like any other thing on earth, all of those have strengths and weaknesses and it’s us to decide which features fit in our projects, or whether we should even consider employing the framework after all.

While learning Struts, Spring or jQuery wasn’t that difficult, when it comes to databases, Hibernate and now NoSQL things get trickier. Both Hibernate and MongoDB are quality products, and I know many successful projects built on top of them, but that doesn’t mean they are easy to use. If you want to employ them, be prepared to learn a lot, there is no other way.

When I started using Hibernate I was overwhelmed by its complexity. I soon understood I couldn’t catch things up without thoroughly studying it, and that’s why I decided to fully read all the 900 pages of Java Persistence with Hibernate. And that was just the beginning, as even now I continue reading and checking its source code every now and then.

Then MongoDB seamed like a good fit in many of our projects, and since I knew nothing of NoSQL, I had to invest quite some time to be productive. Luckily MongoDB offers free on-line classes and once again I had to get back to studying. If you ever had to work with MongoDB aggregation framework you know what I mean.

Continue reading “Why I never blame open source projects”

How to retry JPA transactions after an OptimisticLockException

This is the third part of the optimistic locking series, and I will discuss how we can implement the automatic retry mechanism when dealing with JPA repositories. You can find the introductory part here and the MongoDB implementation here.

JPA requires running the Persistence Context code inside a Transaction, and if our Transaction Manager catches a RuntimeException, it initiates the rollback process. This makes the Persistence Context unusable, since we should discard it along with the roll-backed Transaction.

Therefore it’s safer to retry the business logic operation when we are not within a running Transaction.

For this we altered our @Retry annotation as

public @interface Retry {

    Class<? extends Exception>[] on();

    int times() default 1;

    boolean failInTransaction() default true;
}

We here added the failInTransaction property which is set to true by default.

Continue reading “How to retry JPA transactions after an OptimisticLockException”

Optimistic locking retry with MongoDB

In my previous post I talked about the benefit of employing optimistic locking for MongoDB batch processors. As I wrote before, the optimistic locking exception is a recoverable one, as long as we fetch the latest Entity, we update and save it.

Because we are using MongoDB we don’t have to worry about local or XA transactions. In a future post, I’ll demonstrate how you can build the same mechanism when using JPA.

The Spring framework offers a very good AOP support and, therefore, it makes easy implementing an automatic retry mechanism, and this is how I did it.

Continue reading “Optimistic locking retry with MongoDB”