Philip Grove

The server is question is a pure and dedicated server so no GUI of any kind and nothing is installed except the things Tomcat need. The apps saves to a database but even that runs on another server.

The 60% memory usage is for the java process run by the tomcat user so it is the server and nothing else, and even if has allocated all 128 MB of heap it still leaves 232 MB to the JVM and other data for the java process.

The app does not use native code in the form of methods declared native, but it does use instances of classes implementing the interfaces in java.sql and those are known to cause problems if used incorrectly. But I have been over code several times and that does look like clean use of those classes, also a problem involving those classes would show up in the heap as they are Java objects.

I am developing a web app that runs on a Tomcat server but the server keeps getting killed because of memory usage, and I have no idea what is wrong.

The server itself is rather small, it only has 600 MB RAM, the heap is limited to 128 MB but checking with VisualVM while in test suggests that it barely crosses 75 MB on the heap so the limit should not be an issue. This leaves me confused because it suggests to me that it is the VM itself that uses too much memory which I have never seen or heard of and has a hard time believing. Watching the server with "top" while running showed a physical memory usage of almost 60%, that is 360 MB RAM.

The old server shows similar signs. It has 1.5 GB RAM and while idle "top" shows a physical memory use of 91.2%. It does not get killed but has to be rebooted daily to avoid problems as ending the java process is the only way to get it to release the unused resources.

The issue cannot be reproduced in test, but that might be because the test machine runs Tomcat on a different platform (Windows, while both servers run Linux) and has significantly more RAM (12 GB) so the relative usage is smaller.

During analysis of a heap dump I found that the value in my main HashMap is not a substring as put there, but the complete string and an index pointing at the substring. Is it smart enough to reference the same string or does it clone the string, which would result in excess copies of the same string in memory?

I know from my analysis that the HashMap in question takes up over 15 MB of the heap, but a similar thing happens with the key and it comes from a different string for every different value (approx. 85 different values). By my calculations it should contain less than 5 MB of data in keys and values so where does the remaining 10 MB come from?

Jelle Klap wrote:This maybe related to a JIT compiler optimization that recompiles a method it throws a certain exception a couple of times. After recompilation the compiler can throw a pre-allocated exception, which naturally doesn't have the correct, or rahter any, strack trace.
Though this was a "bug" in the Hotspot server JVM, you seem to be using an Java 6 compatible IcedTea JVM. So I'm not sure if the same workaround applies to it, but for the hotspot VM there's a flag -XX:-OmitStackTraceInFastThrow that turns of the JIT optimization.

Reading through various pages on the internet I was lead to believe that this issue was in fixed in Java 5 and later.

I have been considering this case myself, but the NullPointerException in question was the first the system had thrown in several weeks, so pre-allocation seemed like a wasteful operation given as NullPointerExceptions are quite rare.

Jeff Verdegan wrote:
Then that's not a stack trace. That's just the exception's toString(). Did you study my code and its output?

Then that's a bug somewhere in Java, or in the general understanding of how Java works. Because I know for certain that that is the result of calling printStackTrace on the instance of Exception.

I read your code, but studying it is pointless as it tells me nothing I didn't already know. I do know exception handling a everything that comes with it, this is just a case I have never seen before in my over 13 years of programming Java.

The stack trace gets printed in both the email and the log entry and is just "NullPointerException" is both cases so something has destroyed the stack trace or it has never been anything else. In the case of the LogMailer by printing to a PrintWriter that wraps a StringWriter and then calling toString on the StringWriter, exactly how it happens in the Logger is a mystery because I do not know which method in invoked, and thus how it is handled but since the LogMailer gets invoked first I am pretty sure what the stack trace originally looks like. So it is not lost because nobody prints it, it appear to be lost because nobody sets it or somebody destroys it.

In all my years of programming Java I have never seen this happen before, so a quick (I hope) follow up question.

I understand fully well that by catching Exception we have entered the realm of exception antipatterns, but why does it squash the stack trace?

Here is the way that I see it, please tell where my assumptions goes wrong.
NullPointerException is a subclass of RuntimeException which in turn is a subclass of Exception, so the NullPointerException is caught and long as nobody does anything to e other than read from it the information should remain unchanged. The only possibility I see is that if same thread throws another exception, but since execution of the try block ended the very moment the NullPointerException was thrown that does not seems possible. Other threads should have references to other Exception objects if something happens in them, so e should be unaffected by them.

I get notified (the system sends an email, and logs in a database) that an exception has occurred in our system, just to find that it was a NullPointerException without stack trace. I would love to find out what happened but without stack trace I am having a hard time tracking down the issue. I am looking for reasons for this to happen, I have seen reports related to performance optimizations but those reports are related to Java 1.4.2 and the issue should have been fixed with Java 1.5.0. I have given up trying to track down the exception and is trying to prevent it from happening again.

Our system runs as a servlet on Tomcat on a dedicated server.

"java -version" on the server output this version information:
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.9) (6b18-1.8.9-0.1~squeeze1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

We do use the log4j logger, but as the email is sent prior to logging it should be unaffected if that is causing any problems.

Splitting the con.close() invocation out into its own method gives the risk of forgetting to invoke that method, but at the same time opening and closing the connection provides overhead so doing it as few times as possible is generally a good idea.

Do not use the finalize() method for housekeping. They are meant for objects holding native resources, and while a connection is a native resource there is also no guarantee that they will ever run.

I would suggest a model with three tables. One for users and ID, one for potential roles and ID, and a relation table that has a tie between user IDs and role IDs. I have used this model myself and while it seem more complicated, I have found it simple to use. It does require some more complicated statements but nothing a JOIN can't do for you.

The two table model has the weakness that given a username or ID you don't know where to find the user. Furthermore you run the risk of having two users with the same ID, and as comparing ints is significantly faster than comparing strings you want a unique ID for every user.

MySQL does not support inserting in multiple tables with a single statement, the INSERT ALL statement is specific to Oracle databases.

To me it sounds like you have three statements:

INSERT INTO Address

INSERT INTO Owner

UPDATE Address

Three statement on two tables from one action sounds messy, my first thought though is that you should verify your design because you do not seem to have a single location to store data. Of course such a design could be needed in certain places but you should explore other options before you implement it.

I advice caution when posting preformatted code, I think it's the formatting that complicated things.

Try a GROUP BY with a CONCAT and post the results.

You misunderstand what I mean by inconsistent. For IDENTITY=500000002 you have the ROLECODES 30 and 40 in the first table, and ROLECODE 40 twice in the table, that is potentially confusing.

The fact that you use DB2 9.5 might not be relevant as it is an SQL database and so far the attempts have been pure SQL.

By now I seriously doubt that adding a GROUP BY will actually solve anything, but try it anyway and post the result.

Now we're getting into the obscure corners of JDBC, because I suspect that it basically uses a LIMIT keyword on the statement. But judging from the documentation I think it can be used.

In a time-space trade off involving JDBC I always recommend time winning and the extra space be used. You also run the risk of people clicking "next" and waiting a long time while the code is getting the rest of the results.

Which connectionwaitTimeOut?