Wednesday, September 2, 2009

Great Example of How Our Users Help @mach_ii

My former co-worker Brandon Culpepper (who is still one of the quickest studies I've ever had the pleasure working with) ran into a bit of a bizarre issue with Mach-II yesterday, and after hearing him describe it I was determined to get to the bottom of it.

The gist of the problem was that for some reason after a session timeout occurred, the application would throw a rather non-descript error along the lines of "Element {directory name} is undefined in a Java object of type class coldfusion.runtime.ApplicationScope," and a slightly different error in OpenBD. You can read the full details in the ticket.

Brandon described the issue to me in great detail over IM, but it was one of those things I had to run locally to really get my head around it, and he was nice enough to take the time to not only whittle the problem down to a very specific, repeatable test case, but he sent me two different test applications that had only the elements we needed to be able to repeat the error and figure out what was going on. This was no small amount of work on Brandon's part and was tremendously helpful in getting to the bottom of the issue.

Using these sample apps I was able to figure out that it didn't throw the error if the hyperlink or AJAX call involved was a Mach-II event as opposed to a plain old URL, and at that point I submitted the ticket because I knew Peter, as lead developer of Mach-II, would be able to diagnose things much more easily than I could.

So Peter jumped on the case and figured it out rather quickly. It turns out that this is a rather weird bug that goes back probably to Mach-II 1.1.1 and has to do with the way Mach-II has auto-generated the MACHII_APP_KEY property based on directory names. If you hit a .cfm file or remotely call a CFC in another directory, that will trigger a change in the app key property, and since the app key property changes, Mach-II will think it hasn't been loaded. Note that this only occurs if you don't explicitly set the application key (which I always do), and only reared its head with the introduction of the onSessionStart/End methods in the Application.cfc boostrapper.

Peter came up with a fix that's currently being tested, and he makes note of it in the ticket, but I'll test posterous's code handling and stick it here:

<cfparam name="MACHII_APP_KEY" type="string" default="#GetFileFromPath(ExpandPath('.'))#" />

Note that you can also explicitly set the MACHII_APP_KEY variable to your application name as opposed to relying on the directory name and this will also fix the problem:

<cfset MACHII_APP_KEY = "whatever" />

So I wanted to take a moment to thank Brandon for notifying us of the bug and doing quite a bit of work to help us come to a quick rationale behind and resolution for the bug. Without the diagnosis and sample apps from Brandon this would have taken a lot longer to figure out, and due to his work all Mach-II users will benefit from Peter's fix to a bug that would likely bite others from time to time.

Another great open source success story. Thanks again Brandon!

1 comment:

Peter J. Farrell said...

FYI, the real fix is:<cfparam type="string" />The fix listed is the old code (sorry, if I messed on the code on the ticket).