There's anew CF podcast in town at cfconversations.com. The first episode features a roundtable discussion between Rick Mason, Adam Haskell, Aaron West, and Jeff Coughlin. You can subscribe to it via iTunes here.
By now you should know that it's best practice to keep debugging turned off on production servers. Even when debugging is restricted by IP, ColdFusion busily goes about collecting debugging information for every page request, even though it's not displayed on the screen. All this extra activity tends to slow down the server a bit, particularly if you have "Report Execution Times" selected. Under load, having debugging turned on can have a serious impact on performance. Even in development, turning on "Report Execution Times" can have a significant impact if alot of developers are sharing one dev box.
So you know you should have it turned off in production, but inevitably you're going to need to debug something in production sooner or later, and turn that evil debugging switch back on for a moment. Occasionally you're going to forget to turn it back off. Occasionally the wrong person gets access to the CFAdmin and turns it on just because they don't know any better. However it happens - chaos, anarchy, and mass confusion are likely not far behind.
Wouldn't it be nice to be able to automatically detect that debugging it turned on and send yourself a notification or alert so you can shut it back off? Oh, but you can! Here are a couple of code snippets that you can drop into your Application.cfm or Application.cfc file to fire off an alert to yourself.
Or, if you want to get a little more complicated and detect that template execution times are being calculated (maybe on a busy dev box), you can try this one:
Both of these should work in CF6 and above, but I've only tested them on CF8.
It was interesting to see a recent post on Joel Spolsky's blog explaining that a recent service outage in their hosting environment was caused by accidentally setting their switch to auto-sense network speed. In the post, he acknowledges that they do normally set the network speeds manually and turn off autonegotiate but that one switch had slipped through the cracks.
Leaving autonegotiate turned on can cause all sorts of sticky problems on a network because during negotiation a switch can drop packets. In an office network this is less noticeable, but in a high load environment it can really toss a wrench into the works.
In fact, as reflected in this post on the short lived CF-Guru blog you can see that this same setting can cause CF to potentially hang and depending on load, eventually fail.
So consider this a friendly reminder. In production environments, peg all the switches and NICs to a set speed.
So I'm working on this project right now that requires me to connect to an old JD Edwards system running on a DB2/AS400 platform. For the past two days I've been ripping my hair out trying to figure out why certain tables/columns returned from the JDBC driver (called JT400) are in Binary format. Come to find out that a lot of older AS400 systems use a data format called EBCDIC, which is basically a alternate to ASCII that's built for easy compatibility with punchcards. Yes, you read that right - PUNCHCARDS.
Basically, everything I expected to be a varChar was coming back from the AS400 JDBC Driver as a Binary/ByteArray object in CFMX. I looked high and low for an explanation and finally found the JDBC configuration options for the JT400 Driver. Looks like there is a connect string option that tells the JDBC driver to convert the binary types into varChar!
Once I found this information, all I had to do was add "translate binary=true;" to the end of the JDBC URL and all was good! A couple of notes here though... 1) Yes, there is a space in there, and yes, you should leave it in there. 2) Case matters - lowercase the whole thing or it's not going to work.
For some unknown reason, I held onto the conference packet from the first ColdFusion conference ever, organized by Robi Sen and Mark Broner, held in 1998 at Colorado State University in Fort Collins Colorado. I've scanned some of the contents of the packet and put them online. Come check em out for some nostalgia.
Notable content includes:
Note that you can click "show all sizes" at the top (you may have to be logged into Flicker to see it) if you want to see the full size images.
As I'm getting more and more into developing Flex 2 apps, I am running into silly little annoying problems and am going to start blogging them so I can find the solution when I forget and it happens again.
Problem: The ColdFusion Wizards in the Flex Builder 2 require you to connect to the CFMX server using RDS in order to get table information. In my case, I was getting to the screen where you choose an RDS server and datasource - but and the datasource box was empty. I knew there was a valid datasource at that location, and Flex Builder wasn't complaining that I'd given it a bad RDS password.
After a bit of troubleshooting, I found the following in CFMX's exception.log file: "File not found: /CFIDE/main/ide.cfm". This essentially means I didn't enable RDS when I installed CF. Whoops.
Solution: Since main/ide.cfm isn't an actual physical file, you have to tell CFMX that you want it to intercept calls for this file and handle them for you (enabling RDS). This is done via an entry in the web.xml file, typically located in [cfmxroot]/wwwroot/WEB-INF/. Just open up the file and do a find for "RDS". Two entries should be in there, both commented out. Simply uncomment them and restart CFMX.
Done.
As a side note, if Adobe's listening, it would be nice if Flex Builder were smart enough to tell you when RDS authentication fails or RDS isn't enabled on the target server.
Ben's coming to town May 1st! I just posted details to the SDCFUG website and it should be a good one since Ben's promised to demo ColdFusion integration features never yet seen outside of Adobe!
Hope to see you there!
As it turns out, coldfusion.runtime.Array datatypes turn into java.util.Vector datatypes after WDDX deserialization. This isn't much of a problem for the most part. After all, the CFMX Array datatype is based on the Java Vector datatype. CF still views it as an array, and you can still treat it just like an array in CF code.
However, there is at least one place it *does* matter - invoking and consuming webservices. It seems that when one of these java.util.Vector datatypes is passed to certain webservices, you will get the infamous and annoyingly indescriptive error that it "Could not perform web service invocation "X" because java.lang.IllegalArgumentException: argument type mismatch".
Yowza.
I've confirmed the behavior with some folks at Adobe, so hopefully it will be corrected with the Scorpio release. In the meantime however, I am getting around this problem by recreating/rebuilding the array before posting it to the webservice. A little annoying, but it works.
If you want to test this gotcha yourself, here's some sample code to play with:
Being built in the spirit of Ruby on Rails, ColdFusion on Wheels is very promising.
As posted to Slashdot today, the source code for an algorithm has been posted that promises to find MD5 collisions, making it even more important to add some salt to any use of hash().
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
