Nightmare java leak… with loop and jdbc

Question

When I run the following code in the profiler, I get a char[] and byte[] that build up until the program crashes due to a java heap out of memory exception. Can someone tell me

Answer 1

I would change this:

                        statement.executeQuery(rawQuery);
                        results = statement.getResultSet();

to this:

                        results = statement.executeQuery(rawQuery);

The latter is certainly the API-approved way to do this, and while I can't say for certain that the former is a problem, it certainly seems like it could create two separate result-sets, of which you only close one.

Answer 2

I would suggest you try two things:

Extend your timer to about 10 seconds. Two is expecting a lot for a slow system.

Put a Thread.currentThread.sleep(10) (or similar) in your idle loop.

I expect you are not waiting for go to complete. While you are spinning on air in your idle loop the database connecion is dying from lack of cycles and every two seconds you add yet another connection and query. No wonder the poor thing is struggling.

Answer 3

Unfortunately you don't specify some details about the problem, for example, how big is the result set (# of rows), and how long does it take to run into out of memory exception.

I don't have access right now to the mysql driver you have, but I ran your same code with an H2 database, with 1000 rows in the myTable. The heap size of the JVM was stable during the test, without any memory leak. You can see that in the attached screenshot. The heap size increased a little, then returned to the original position after the GC, up again, down again, on a very stable pattern.

You can run your app and then run the Jvisualvm and connect to your app to see, for example, if the number of results from the database is too large to fit into the existing memory. Which is my guess. In this case the blue line will rapidly go over the max memory.

If that's the case you run your application with -Xmx setting to increase the memory size.

If indeed there is a memory leak it is not in your code, but in the driver you're using. To confirm a memory leak, the blue line in the chart below will go up (allocating memory), the GC will run (freeing up memory) but the blue line never gets back to it's original position leaving behind some objects.

Answer 4

Add the heap dump on out of memory arg and then look at the heap with mat or similar. Using HeapDumpOnOutOfMemoryError parameter for heap dump for JBoss