Zend Framework and File Locking Pitfalls
Earlier today while reading through the Zend Framework 1.6 RC1 release notes I've come across an interesting bug that has been fixed: [ZF-3382] Zend_Cache_Backend_File problems under very high load.
There are a lot of things to say about this issue. The obvious ones first:
1. Under typical operation such as opening, locking, reading/writing, and then closing a file you should never need to unlock a file explicitly since fclose() implicitly unlocks a file. Calling flock(LOCK_UN) explicitly merely introduces a potential race condition between the lock release and file close. And it'll be (very) hard to debug.
2. PHP's fopen() has a bug when using "wb" (overwrite in binary mode). Instead, "ab+" (append in binary mode) followed by a fseek(0) and truncate(0) eliminates another potential race problem. Roof Top Solutions has an article on this.
Honestly, these types of bugs are of the worst kind particularly because they're rather hard to identify. The buggy code runs and seems fine, but will fail when you need it the most; under high loads, such as when you're on digg, slashdot, or any other large site that sends massive amounts of traffic your way. Suddenly, instead of helping your site scale, it causes your web application to thrash while the cache files are getting clobbered and trampled on.
Now imagine this is an issue with your in-house component that you have to solve by yourself. First it would have to be isolated and identified because the big picture is just that your application crumbles under high load — "even with all the caching that it's doing. Not sure what's going on", might be the first thought. I know that it would take me quite some time to actually narrow it down to the caching layer, create stress tests, experiment with various backends to see if, say, using memcache vs. files would fix the issue. And that's just identifying the problem. When it comes to fixing it, not explicitly unlocking isn't too hard to figure out, but the issue with fopen() in "wb" mode? That would have taken a while. Case in point; looking at the issue ticket, it was created June 4 and resolved on June 26, and judging by the notes, largely due to the efforts of Cody Pisto, who spent his afternoon on June 25 identifying the problems and creating a patch for this tricky issue.
Furthermore, this is a great example of the benefits gained from the Zend Framework (and other open source frameworks and components). In buzzwordy marketing lingo: It's a time and battle tested feature rich platform of loosely coupled components that you can mix and match as you please, and it only gets better as its adoption rate increases.
Print This Post
Bugs in Phing on Windows
I use Phing to deploy my projects, and as they become more complex I expand on my use of Phing tasks. For instance, I have a ZIP archive of zip codes that Phing extracts and then imports into a database when deploying the application.
I maintain two development environments. One on a Linux server, and one locally on my Windows laptop using WAMP. So naturally, my PHP projects are cross-platform compatible and run on either Windows or Linux. And for the most part that simply means being careful about buildings paths, filenames, and file permissions.
To my surprise, the Unzip task defined in my build.xml that imports the Zip code data failed in mysterious ways: It reports success, but there's no extracted files to be found. It works on Linux, but not on Windows.
I dug into it and found two issues. First, the Phing's Unzip Task doesn't have the most solid error checking, and errors coming back from the Archive_Zip PEAR component. Second, the Archive_Zip PEAR component doesn't correctly check for absolute paths on Windows. Both problems have been reported on Phing's web site as Issue #261 and #262.
Print This Post
Debugging web sites with the BlackBerry Simulator
I've never used a BlackBerry. Yet, I was tasked with debugging a web site that apparently had some issues with the BlackBerry. This rather outdated site was using frames, which is the first hint that there may be problems. However, according to the BlackBerry Developer's Guide (PDF) frames aren't an issue. They're simply processed and displayed sequentially in the same order they're defined in.
First thing I needed to do is grab that BlackBerry Simulator, a Verizon-branded 8130. Also needed is the Email and MDS Services Simulator, which enables the BlackBerry Simulator to use the Internet Browser, and have email functionality.
After that it's all fairly straight forward. Start the BlackBerry Simulator, fire up the MDS Services, go to Applications, open the Internet Browser, navigate to the desired site and look at the results.
And it wasn't pretty. Everything showed up correctly — well, as correct as it can on such a small screen — but some of the links were simply not working. Normally the cursor turns into a hand icon when hovering over a link, but it wasn't happening. Initially I thought maybe there was a style sheet issue, where perhaps the "hitbox" for the actual link had moved or been covered by something. However, that turned out to not be the case.
I employed a strategic debugging methodology which mainly consisted of "remove code until it works." And so I stripped down the files, deleting sections of html at a time — figuring it would eventually all fall into place. But it wasn't so. After I had reduced both frames to valid html in its simplest form — html, body tags, and a list of five links — the issue became apparent. There's a bug in the BlackBerry Web Browser. When the frames are merged, all links, except for the first two per each frame, are unclickable. They still look like links, they're blue, they're underlined, but when you hover over them with the cursor it doesn't turn into a hand, and the links are simply not clickable. They behave more like an a tag without the href attribute.
Print This Post
Ubuntu 8.04 on a Sony VAIO VGN-FE890
This is a follow-up to my Ubuntu post from a few days ago. I've tried out the final version of 8.04 LTS on my Sony VAIO laptop, and found that it didn't boot. Instead, after the Loading Kernel process bar reaches 100%, the only thing that appears on screen is:
[ 42.947514] ACPI: EC: acpi_ec_wait timeout, status 0, expect_event = 1 [ 42.947575] ACPI: EC: read timeout, command = 128
And unfortunately that's where it ends. No CTRL+ALT+DEL, the only way to turn off the laptop is to hold down the power button for 5 seconds.
So apparently there's an issue with the ACPI, and indeed, it's something that's already being talked about.
I didn't actually install Ubuntu on the laptop, but I wanted to check it out from the live CD. My workaround is to hit F6 twice in the boot menu — once to get a command line interface to be able to add and modify the options, and the second time you get a popup. From there, conveniently select the first option, which is "acpi=off", by hitting Enter. Press ESC to close the popup, and hit Enter to boot. Of course ACPI will be disabled, but at least you'll be able to get into Ubuntu.
Print This Post