ColdFusion “null, null” errors – CFInterface another possible reason

by kai on 24/12/2011

Just recently I was hunting a “null, null” error in a large ColdFusion application. It started occurring all of a sudden under decent load and it was unfortunately rather hard to reproduce.

Some basics: If you’re getting a “null, null” error in ColdFusion (and yes, this still does occur in ColdFusion 8 and 9 occasionally, even though there was a certain known issue in CFMX 6/6.1 that was fixed with a hotfix), that almost always points to a Null Pointer Exception somewhere in the Java application that ColdFusion is nowadays. You will also see an HTTP status code of 500 and not necessarily any log output in the ColdFusion logs. Note: double check the JRun log files, you might get some additional information from them.

The reason why you’re getting a “null, null” error in the first place is essentially because you’d be using a CFERROR tag or any other global error handler while your application ran into that Null Pointer Exception. This has been very well explained by Steven Erat and is also noted in an Adobe technote. The best way to find out more about the issue is to actually remove all of those and then have a look into what the error is really about. That might prove tricky if the error just happens sporadically, seems to be impossible to reproduce and “obviously” just hits you on production, never on dev/test or under any artificial load test scenarios. Doh. When our instance of the “null, null” error happened it was usually during night time and hard for us to debug and get into it.

Just the other week though, the error happened during day time while I was working on-site at the client’s premises and we had a chance to jump on the production system, isolated the particular CF instance from the production cluster and started digging. After switching off all the error handling we found the following error messages per occurrence of the “null, null” error:

22:41:39.039 – java.lang.NullPointerException – in {filename} : line 247
22:41:39.039 – coldfusion.util.RuntimeWrapper Exception – in {filename}: line 247
22:41:39.039 – java.lang.NullPointerException – in {filename} : line 247

That’s something to work with. The application is actually a large-scale Fusebox 5.5 application therefore {filename} pointed to a FB-parsed .cfm file. So – we were looking into the mentioned lines (there were a few other versions of this NPE in different areas of the site) and they all had in common that they were calling out to CFC instances in CF’s application scope (let’s call that A.cfc from now on – or better: application.A – and let the method we called be .doSomething()).

From there we looked into the application.A and the .doSomething() method that was being called and there was absolutely nothing wrong with it. Within .doSomething() a few function-scoped variables were created that itself pointed to other CFCs in the application scope in the further course of .doSomething() – but again there didn’t seem to be anything wrong with that. We went ahead and removed the code from within .doSomething step-by-step to identify what would cause the NPE. Funny enough – nothing seemed to work. So we removed all the other methods from application.A until it was literally a barebone CFC structure with only an empty .doSomething() inside. Still, every request would bomb with a NullPointerException exactly in line 247.

All of a sudden I realised that application.A was actually implementing an interface (for the sake of it, let’s call it IA.cfc). IA.cfc prescribed that its implementations were supposed to have a .doSomething() function and it was working just fine in the vast majority of cases. However – removing the implements=”com.bla.IA”-atrribute in application.A fixed the NPE and the application started working again. I have absolutely no idea what happened here and why this particular implements-attribute would cause a NullPointException in some circumstances, but it did. As I said before – the application was working fine with such an architecture for more than a year. All of a sudden (and that might have been triggered by a CF- or server update or anything else) it started to occasionally get into a situation where all the app-scope’d CFCs that implemented an interface were creating those issues from time to time.

Now – if you’re having trouble with “null, null” errors in ColdFusion I definitely do not want to suggest that it is due to CFINTERFACE. In fact, most likely it won’t. There are tons of discussions out there that talk about various reasons and “solutions” for “null, null” errors such as Client variables, Cookies, Unix ports, Database drivers etc. The reality and the message to take from this is – please repeat that after me: all those are NOT reasons for the “null, null” errors. The “null, null” errors are just covering up the real NullPointerException you need to look into. In our case it was a weird behaviour of CFINTERFACE, in other cases it might be Query of Queries or whatever else. There’s NO unique solution to a “null, null” error, just a unique path to a solution.

{ 1 comment… read it below or add one }

David Levin August 12, 2012 at 6:58 pm

Thanks for posting the detailed information. I get null null errors after every reboot of the ColdFusion server on the first load of a CFC. The information you provided should give me some clues as to how to identify what could be going on.


Leave a Comment

Previous post:

Next post: