I'm testing out CF2016 Enterprise as a possible upgrade for my existing CF9 application, and I'm running into a major issue with existing code that works fine in CF9 where I read a BLOB image from my Oracle database and write it out to my filesystem as a JPG.
The code looks something like this (redacted for security):
... Query "GrabImage" reads image as "image_blob"...
<cfimage action="WRITE" source="#newimage#" destination="/xxxxxxxx/images/cf/#imagefile#" overwrite="true">
The error showing up in my exception.log looks like this:
This happens every time I do this action of writing the image file to the filesystem, but the ImageWrite call does work, and the image ends up on my filesystem and serves up perfectly. I tried finding information online about the ExifMetaDataHelper thing, since that seems to be the root of the issue, and it sounds like BLOB images don't carry the EXIF metadata when read by cfimage, and so that would explain that error trying to write an image without it, though it's strange that it just errors in the background and still completes the action.
I tested out what would happen if I read the image FILE instead of the BLOB as my source, and when I do that (read the file and write it back), I don't get that error. There's no actual EXIF metadata (a dump shows an empty structure), but it doesn't error. So the BLOB source does seem to be the problem.
What's most troubling about this is that under load, this error seems to swamp the CF server. Running a few of these at a time just errors into the exception log, but if I make too many near-simultaneous calls to this function, my server stops responding. CF doesn't seem to be maxing out my Java heap or anything, but it just stops handling requests. The exception.log starts rotating pretty quickly, but even that shouldn't make it unresponsive. Requests start timing out and eventually the exception log stops logging most of that trace, just recording the "NullPointerException" line.
With 2016 being such a recent release, I can't find much related to known bugs. Anybody seen anything like this? The same error occurs if I do writetobrowser instead of just write, which isn't even an option since I need to maintain consistent URLs for those images.