Web Development By George » Model-Glue

Limit on CFC Size?

George — Fri, 08 May 2009 01:45:03 +0000

So a few months ago I wrote a post about a java.lang.StackOverflowError I had experienced with Model-Glue and ColdSpring. You can read about it here and here. We it reared it’s ugly head again today. I’m not sure exactly what is happening and maybe someone with a better knowledge of ColdSpring can help me out here. I solved the problem by moving my new function into a different Service.cfc. Why this worked? I don’t know, but it seems that it has something to do with the size of the file. It’s only running about 1500 lines in the service, but I have another service with more functions that runs 3000 lines of code. But moving it out, definitely solves the ColdSpring compile error and allows me to move forward with development.

Any thoughts out there?

java.lang.StackOverflowError

George — Wed, 11 Mar 2009 15:10:52 +0000

I’ve been working on building a fairly large Model-Glue application and it’s been up and running for going on 4 months. Yesterday I was working on some of the planned enhancements when I ran into a 500 ROOT CAUSE: java.lang.StackOverflowError problem. I’ve tracked it down to one instance of adding one referenced bean onto one of my service instances. I can comment out the bean and everything compiles. I can change it to one of my DAO beans and it works, I change it to another of my service beans and it causes the StackOverflowError again.

I have moved some of the ColdSpring.xml out to includes to reduce the file size and that has had no effect. I updated to 1.2 and had no change either. I’ve seen some minor changes in the rest of the error stack when I change up the service I’m including, but it’s more often than not this as the next couple lines:

at coldfusion.runtime.LocalScope.bindInternal(LocalScope.java:373)
at coldfusion.runtime.LocalScope.bindInternal(LocalScope.java:387)
at cfAbstractBeanFactory2ecfc1246833417$funcRESOLVEBEANNAME.runFunction(coldspringbeansAbstractBeanFactory.cfc:193)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418)
at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192)
at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2471)

followed by a repeating of the above with several other calls to the cfAbstractBeanFactory instance. I know I’m not providing much, but I’m absolutely stumped as to what can be causing the problem. The bean I am adding that causes the error is also used as a ref bean on another bean without causing the problem. Any ideas that I could poke around at would be much appreciated!

ColdFusion Server Monitor

George — Wed, 25 Feb 2009 15:50:09 +0000

So last week we had a site running amok on one of our CF8 servers so we decided to use the ColdFusion Server Monitor to see if we could figure it out. Well starting the thing pegged the server’s processors to 100% and we couldn’t get anything done, so we rebooted the machine. After reboot – since it was the middle of the day and all – we noticed that several sites were not coming back up. So we started looking around on the Internet for ways we could fix it. The sites that weren’t coming back up were all Model-Glue run so we thought it might be something in that. Producing the CFLoop error when the application was trying to compile for the first time.

Well after some digging, I came across several posts by people mentioning how Sean Corfield had talked about the JRE version included with CF8 was experiencing a bug in the way it compiled components – something that any Model-Glue application is going to do extensively at startup as it tries to build the entire library for ColdSpring. You can read about it here - ColdFusion 8 And Java 6. So we changed out the JRE version overnight to the newest release of Java 6 Update 12. We were still having problems with the sites compiling though, so we switched to 11. Still no joy.

So we were getting a little concerned – it was going on a full day now since we had the sites go down. So we said – well let’s try that Server Monitor again and see if we can tell what’s happening with it. So we fired it up expecting the worst and saw that all of it’s options were still running. Basically, restarting the server hadn’t set the Server Monitor back to an Off position. Once we turned all the options off and saved it, the two down sites started again. Unbelievable!

So the side note is, having found the article by Corfield, we have a more responsive version of ColdFusion 8 with Java 6 running on our server. I think I can notice a difference, not sure if the clients can or not, but I know it made for a happy day once everything came back on line.