Mike Munhall

In our ongoing quest to finish the ColdFusion 4.5 to MX 7.01 upgrade, we ran into another snag that had our heads spinning for a while. As we were migrating servers from 4.5 to 7.01, we were getting more and more frequent “unable to create new native thread” errors and complaints from customers about servers being unavailable or just general latency.

During this time, we also had reports of two particular pieces of functionality that were not working at all. The two pieces of functionality that were not working had one thing in common: they were both instantiating objects from the MSXML API. We were using Microsoft’s XML API in ColdFusion 4.5 because 4.5 obviously doesn’t have an XML API of it’s own.

Well, as it turns out, the MSXML API was reaking havoc on the system. Essentially, if MX attempted to instantiate an object from the MSXML API, all operating system threads would immediately get eaten up and the MX server would just hang or die. What’s worse is that a restart of the CF services would not alleviate the problem. The OS threads would remain unavailable until the entire machine was restarted.

We didn’t bother trying to find out why CF wasn’t playing well with the MSXML API. The solution, as you would guess, was simple. We just had to rewrite the XML routines using the native ColdFusion MX tags and functions. We were using the TorchXML 3rd-party XML parser (which leverages the MSXML API) to parse XML documents. The TorchXML API is similar to the ColdFusion XML tags and functions in the fact that you work with a complex structure to access and work with the data in the XML. We simply had to replace a few strings in each implementation of the parser to get it working in MX:

Trackback URI | Comments RSS