Comments on: Memory, memory everywhere and not a byte to eat http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/ Learn the newest innovations in Java and unleash explosive new techniques of the technology age. JavaRant teaches you how to use the latest strategies with classic principles to help you become an expert in this exciting revolution. Whether you are new to Java or are a seasoned veteran, you’ll discover new ways to boost your productivity and understanding. You’ll learn about tools to make you faster, frameworks to aid in applications, servers to make your apps run faster, and much more. We’re dedicated to teaching you not only the skills but also the mind set necessary to succeed as a Java programmer. Come join our community that contains thousands of professionals working to keep their edge. Sat, 22 Nov 2008 14:45:53 +0000 http://wordpress.org/?v=2.5 By: jeffrichley http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-39 jeffrichley Mon, 21 Apr 2008 18:13:02 +0000 http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-39 It isn't that the logging isn't guaranteed, it case of a JVM crashing because it is out of memory. When a JVM crashes, it is hard to tell what is going to be completed and what will not. Also, it wasn't so much Hibernate that was keeping it in memory, it was the Log4j loggers that had it queued up. Hibernate was the producer of the data being passed to Log4j. It is much like any production code, you typically don't want to have tons of logging going on when in a production environment, certainly not at a "debug" level. It isn’t that the logging isn’t guaranteed, it case of a JVM crashing because it is out of memory. When a JVM crashes, it is hard to tell what is going to be completed and what will not.

Also, it wasn’t so much Hibernate that was keeping it in memory, it was the Log4j loggers that had it queued up. Hibernate was the producer of the data being passed to Log4j. It is much like any production code, you typically don’t want to have tons of logging going on when in a production environment, certainly not at a “debug” level.

]]> By: Andries Inzé http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-38 Andries Inzé Sun, 20 Apr 2008 19:11:36 +0000 http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-38 Very intresting, it puzzled my mind quite a bit. As you state, Hibernate keeps the logging in memory, until it has time to be processed. Does this mean that, when under heavy load, the logging isn't guaranteed to be written down? I'd thought, when a transaction is finished, all logging of the transaction would at least catch up before starting the next one. I find it very strange that the logging isn't guaranteed. Very intresting, it puzzled my mind quite a bit.

As you state, Hibernate keeps the logging in memory, until it has time to be processed. Does this mean that, when under heavy load, the logging isn’t guaranteed to be written down? I’d thought, when a transaction is finished, all logging of the transaction would at least catch up before starting the next one.
I find it very strange that the logging isn’t guaranteed.

]]> By: david http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-31 david Mon, 24 Mar 2008 01:08:29 +0000 http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-31 That's a great hint Jeff, thanks for sharing this. It's really coincidental that I just wrote a blog post on using 3rd-party libs and bug hunting: http://dlinsin.blogspot.com/2008/03/why-me.html That’s a great hint Jeff, thanks for sharing this. It’s really coincidental that I just wrote a blog post on using 3rd-party libs and bug hunting: http://dlinsin.blogspot.com/2008/03/why-me.html

]]> By: Matt http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-30 Matt Sat, 22 Mar 2008 02:07:50 +0000 http://www.javarant.com/2008/03/21/memory-memory-everywhere-and-not-a-byte-to-eat/#comment-30 Well, Jeff, you and I have had discussions many times on the pros and cons of Hibernate. What's funny is that I have never, ever seen the logging from any system pile up so fast that it ate up all the memory, but it could certainly happen, particularly under heavy load. Two additional things come to mind so you don't have to completely give up on seeing the SQL all the time: 1) Look at your memory settings on your JVM, particularly -Xmx### setting, and the the too-frequently ignored -XX:MaxPermSize=### setting that controls your PermGen space 2) Rather than completely giving up on seeing the SQL, use different log4j settings in prod than you do in development. You can have "hibernate.show_sql" off and still see the sql if you set the logger for log4j.logger.org.hibernate.SQL=DEBUG. Well, Jeff, you and I have had discussions many times on the pros and cons of Hibernate. What’s funny is that I have never, ever seen the logging from any system pile up so fast that it ate up all the memory, but it could certainly happen, particularly under heavy load.
Two additional things come to mind so you don’t have to completely give up on seeing the SQL all the time:
1) Look at your memory settings on your JVM, particularly -Xmx### setting, and the the too-frequently ignored -XX:MaxPermSize=### setting that controls your PermGen space
2) Rather than completely giving up on seeing the SQL, use different log4j settings in prod than you do in development. You can have “hibernate.show_sql” off and still see the sql if you set the logger for log4j.logger.org.hibernate.SQL=DEBUG.

]]>