Julian C. Dunn

It’s funny how sometimes you have a technical problem that you think is only attributable to your own (possibly crappy telephony) setup, but later on you discover that the problem is quite common. For example, today on the TAUG mailing list, someone complained about their Zap (analog) channel never being hung up by Asterisk particularly when the user at the other end hangs up right away. I have also had this problem on my home Asterisk setup, where Asterisk will busy-out the Zap channel for hours, preventing people from making incoming calls.

At first I attributed it to my crappy clone FXO card, but now I’m wondering if it’s a problem with Asterisk. Others seem to think so and feel that Asterisk doesn’t properly handle the supervised disconnect in situations when the channel hasn’t been Answer()ed. I haven’t done enough tests to nail down when in the dialplan it happens exactly.

Later in the day, someone claimed that one way to fix the root cause is to teach Asterisk how to handle the standard off-hook warning tone, but I don’t think it’ll be very simple to implement, since the warning tones are probably different for each country.

For now, I’m happy to ssh into the server and soft hangup Zap/1 (as someone suggested) but I wish there was a solution that didn’t require such manual intervention, so if any telephony enthusiasts are reading this and have any better ideas, feel free to comment.

My colleague Blake recently wrote an article on the occasion of the decommissioning of NewsDelivery, a dynamic content display engine that until recently ran all the news stories on CBC.ca. I can’t speak for any of our alumni, but I think all of us at CBC.ca have learned one lesson:

Large websites should never, ever use dynamic rendering for content rendering.

It’s amazing how many content management systems still do not grasp this principle. On a busy site, especially one that is liable to be Slashdotted or visited heavily (say, on 11 September 2001), you do not want to be executing Java/ASP/Smalltalk/FORTRAN/whatever code every time someone visits a story. In short, you do not want CPU usage to rise proportionally to the number of visitors you have.

What you do want is to make the content rendering "system" as simple as possible; in the ideal case, you can barely call it a system. For content rendering, CBC.ca now mostly uses a bare Apache instances with server-side includes, meaning that aside from the core Apache engine, no other code needs to be executed every time you view a story.

This seems like a very simple principle, but many other news sites are still not grasping it. I can almost guarantee that if there is another 9/11-scale of event, sites that use a servlet-based dynamic execution system like The Globe and Mail and The Toronto Star will fall over under heavy load far sooner than CBC.ca. But I don’t really blame those organizations for choosing, for example, Fatwire Content Server (as in the Star’s case) because a news organization’s primary need is to create content. Displaying it is a whole separate problem entirely and the shame should be on the vendor for closely tying the two together.

Last night I had the rare opportunity to be given a tour of the Toronto Transit Commission‘s Control Centre. The tour was organized by the East Toronto Chapter of the Professional Engineers of Ontario, of which I am a member.

Continue reading…