While Christer were updating his profile on one of our current projects, he suddenly got this rather cryptic message. We tossed a few ideas around, before just leaving it for the day. We came back to the issue earlier today, and I suddenly had the realization that it had to have something to do with the session handling. Changing our session handler from memcache to the regular file based cache did nothing, so then it had to be something in the code itself.
The only thing we have in our session is an object representing the currently logged in user, so it had to be something in regards to that. After a bit of debugging I found the culprit; a reference to an object which contained a reference to a PDO object. PDO objects cannot be serialized, and this exception was being thrown after the script had finished running. The session is committed to the session storage handler when the script terminates, and therefor is run out of the regular script context (and this is why you get “in Unknown on line 0”. It would be very helpful if the PHP engine had been able to provide at least the message from the exception, but that’s how it currently is.
Hopefully someone else will get an Eureka!-moment when reading this!
The solution we ended up with was to remove the references to the objects containing the unserializable structures. This was done by implementing the magic __sleep method, which returns a list of all the fields that should be kept when serializing the object (we miss the option of instead just unsetting the fields that needs to be unset and then let the object be serialized as it would have if the __sleep method wasn’t implemented). We solved this by implemeting the __sleep method and removing our references, before returning all the fields contained in the object:
public function __sleep()
$this->manager = null;
And there you have it, one solved problem!
Just had to debug a little issue with a domain that were not considered authorative from our DNS server. The SOA records were there as they should be, and it referred the correct name server in the SOA record. A bit of searching at Google later turned up the cause of the issue; the name server did not have an NS entry for the domain. To be considered authorative, a domain server has to provide an NS entry for the domain too. As I do DNS stuff only a couple of minutes each year, details like that happily slides away to the darkest corners of my mind.
So to sum it up: Get your SOA and your NS records straight, and you can be authorative all day long! Authorative like it’s 1999!
En route from Slashdot comes an article with examples of the hand writing of several people that design fonts and typefaces for a living. They’re obviously human too, but I actually think that all the provided examples of their hand writing are beautiful in their own way – and should be turned into typefaces by themselves. In particular I’d like to point out Marian Bantjes and Sebastian Lester, but that might be because I’m very fond of typefaces with large decents (read more on Wikipedia’s article about typefaces).
Fresh from the Google Open Source Blog comes news that Google has released their Protocol Buffers specification and accompanying libraries. The code and specification has been release at Protocol Buffers on Google Code.
Protocol Buffers is a data format for fast exchange and parsing of data and messages between computers. It is similar to simple uses of XML in this manner, but the messages size on the wire and their parsing time is very much optimized for busy sites. There is no need to spend loads of time doing XML parsing when you instead could do something useful. It’s very easy to interact with the messages through the generated classes (for C++, Java and Python), and future versions of the same schema are compatible with old versions (as new fields are just ignored by older parsers).
Still no PHP implementation available, so guess it’s time to get going and lay down some code during the summer. Anyone up for the job?
Suddenly encountered the error message ssh_exchange_identification: Connection closed by remote host while ssh-ing into one of the machines facing the public side of the almighty internet today. A quick Google search turned up an article saying that the problem usually solves itself. The reason for this is simple: as this is a box that’s available on the general internet, from time to time a storm of SSH connection requests hits us as other compromised servers attempt to break in. When this happens, sshd may go into defensive mode and just refuse the connections instead of trying to handle them. This is good. This is also the reason why it “just suddenty works again”, since the attack may subside or some resources gets freed up.
There may of course be other reasons for this error, but if the machine is reachable through other measures, answers ping and worked an hour ago, this may be the cause. Guess it’s time to move the public ssh port to something else than 22.
Ulf Wendel is presenting several good articles about the process about implementing the mysqlnd library for PDO as PDO_MYSQLND. I wrote about PDO_MYSQLND when it first was announced, but Ulf has posted two good articles about the implementation of PDO_MYSQLND since then. These articles provide a unique insight into how PDO is built and what challenges lies ahead for PDO2 (.. in addition to the license and NDA debate..)
Remember that you can always follow the latest developments over at Planet PHP.
Five days. That’s all the time the mighty internet of spambots needed to forget that I exists. I feel ignored like that drunken guy that wants to be everybody’s best friend. People tend to look to the other way and make their “He’s just drunk you know” face. I’ve seen it in the eyes of The Internet.
The reason? Not a single spam caught in akismet for five days. I’m lost at sea here. Come back internet spambots. Come back! I didn’t mean what I said! Was it something I did? Please. I’m not that drunk.