In a new post to his site Brian Moon has shared a problem he had with sockets and timeouts and having them perform the same way every time. He walks through the symptoms he was seeing and provides his own solution in the end.

So, it seems that when you try and connect to an IP that is routable on the network, but not answering, the TCP stack has some built in timeouts that are not obvious. This differs from trying to connect to an IP address that is up, but not listening on a given port. [...] After a lot of messing around, a coworker pointed out that in production, the failures were happening for an IP that was routable on the network, but that had no host listening on the IP.

After some testing, Brian figured out that his problem was using localhost for testing and not an actual non-host server. He made the switch and figured out how to set the timeouts low and work with error state checking to make things more stable. He explains a bit more about how the code in his solution works. You can find his solution in this gist on GitHub.

On the NerdMom blog there's a recent post from Jen about her experiences in developing in both the CodeIgniter 2 framework and Kohana 3 frameworks (upcoming versions of both).

For the last month or so I've been developing an app side-by-side with Kohana 3 and CodeIgniter 2 to see which framework fits my programming style better. Nothing terribly fancy; just a simple CMS. [...] In the end it comes down to framework stability for me. And in this case, CI wins, hands down. Don't get me wrong; Kohana is beautifully written and introduced me to a prime example of clean, well commented code.

She talks about some of what she was needing out of a framework and what ultimately lead her to pick CodeIgniter 2 as the tool for her and her development. She notes that, while Kohana is nicely written, they've had some consistency issues with backwards compatibility that have caused issues. She also mentions some of the unstable code that was added just to micro-optimize things when it wasn't needed.

The PHP::Impact blog has a recommendation for those using the memcache functions in their PHP applications - be sure your hashing strategy matches what your script does.

If you are using the Memcache functions through a PECL extension, you can set global runtime configuration options by specifying the values within your php.ini file. One of them is memcache.hash_strategy. This option sets the hashing mechanism used to select and specifies which hash strategy to use: Standard (default) or Consistent.

The recommendation is to set it to consistent to allow for the most flexibility on adding and removing servers from the caching server pool without the need for outside intervention.

Micheal Kimsal has pointed out another "bugbear" he's found in his work with PHP - this time it's with the use of class constants.

My issue is not with the language itself (this time!) but how this sort of documentation is handled. Updating public documentation well ahead of a release creates confusion.

He's referring to the documentation for the class constants not quite matching up with the current functionality (resulting in a T_PAAMAYIM_NEKUDOTAYIM). He wants consistency in the documentation and maybe references to what it requires to use a certain bit of code.