Interesting issue with ORM, Model-Glue, and Exceptions

This post is more than 2 years old.

I'm still digging into this so please forgive me if I completely change my mind later on, but I believe I've found something odd going on with ORM, Model-Glue, and Exceptions. I've noticed this for a little while now but didn't really get a chance to dig until today. I had noticed that when I made a simple mistake while working with ORM (almost always a typo on the column), my Model-Glue application would churn for a while and eventually just return a white screen. Back in my logs I noticed this:

GC overhead limit exceeded The specific sequence of files included or processed is: C:\projects\parishilton\siteone\www\index.cfm'' " java.lang.OutOfMemoryError: GC overhead limit exceeded

If I checked my hibernate log (which I encourage you to do right now) I would see a much more clear error mentioning the mistake in my column. But I was curious - why the GC errors?

I seem to remember something like this from a few months ago - low and behold - I found this thread I had started on the Model-Glue list. It involved exceptions as well. I ensured I had modified my code to not store the exception in the trace, and then I also modified my site's exception template. This is a site still in construction so it was still set to just do a simple dump. On a whim I added a top to it. This is when I noticed something odd.

The exception object contained 3 keys I had never seen before. First was a NextException key. This seemed to be a completely second copy of the exception. Not only that, but I saw it replicated a few times within itself. Also "new" was a ThrowableCount and Throwables key. The ThrowableCount was a number, but Throwables were other exceptions (also with NextExceptions as well).

All in all - the exception was huge and I could begin to see where perhaps the cfdump had caused the out of memory error.

For now what I'm doing is simply using a TOP="3" in my Model-Glue exception handler. Another possible idea would be to use cfdump's hide argument and ask it to hide nextexception and throwables.

I've asked some folks at Adobe for more information on these keys and will post an update when I hear more.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Dan Wilson posted on 3/3/2010 at 1:26 AM

Hi Ray,

Would you clarify the role of Model-Glue in this circumstance?


Comment 2 by Raymond Camden posted on 3/3/2010 at 2:31 AM

I believe - stress - believe - the trace/auto dump was part of the problem. There was the dump in the trace code as well as the dump in the exception view.

Comment 3 by brian posted on 3/4/2010 at 8:01 AM

That tracks with something i saw after upgrading to M-G 3.x (ColdFusion 8) I had a process that sent dumps via email -- normally no bigger than 1MB. After the upgrade, my email box overflowed -- each email was 15MB worth of dump. I knew what app was generating them, and just stopped sending the dumps -- didn't really take the time to analyze why so big. When I have access tomorrow or Friday, I'll see if I can recreate. I just remember thinking WOW, M-G 3.x sure has increased it's footprint in the application/session/catch space.

Comment 4 by Gabriel posted on 3/4/2010 at 10:02 PM

I experienced the same in as part of dumping the exception in an email. Top="3" mitigates the issue. Thank you.

- Gabriel