mult.ifario.us

Never use the same communications channel to both handle load and send management information or control.

Here are two instances of the Nagging Nanny Management Antipattern in action, one with MQSeries and one with Ruby on Rails.

What do you get when you cross queues and topics? In the olden days of FiveSight (like 2000), we had an integration server product that made it relatively easy to hook JMS queues (and other sources of "messages" like directories, sockets, etc.) to business logic. (Think of it as an early approximation to something like Mule or ServiceMix.) The first incarnation of product the used JMS topics to transmit management messages (like "pause", "stop", "deploy") from a management console to one or more remote servers. This was all well and good until our first MQSeries deployment (5.1, I think; more ancient history), and at the time, MQSeries simulated topics on top of its queues. The result was that a heavily-loaded server would be unable to respond to management messages buried amongst thousands of other messages running through the same queue manager. We refactored the design to use a separate communication pathway for management messages, and things worked as intended.

Are you busy? Some folks were making a similar mistake managing web server instances at TextDrive recently. A good number of users were using an innocuous looking nanny script to ensure that their instances of lighttpd/RoR were up and running. However, note that the nanny script asks the server how it's doing by sending a request:

/usr/local/bin/curl -I http://YOURDOMAIN.com:YOURPORT

Thus, if the request times out because the server's loaded down and unresponsive, the nanny script will bounce it, making the problem worse. Some further complications with not cleaning up resources spawned by the killed lighttpd instances made it even more fun.

Steve Shu's entry about cockroaches got me thinking about the flip side of being resourceful and resilient — failure. It's a shame that failure and mistakes have such a negative connotation, because neither need be negative.

I've been meaning to blog about failure as a necessary part of entrepreneurship and a skill to master. The mythology of entrepreneurship is full of people whose "sticktuitiveness" sees them through in the end. Sorry if you just bought a bunch of Horatio Alger books, but that's bu115h!t— more likely than not, those people were continuously questioning their intuition, making subtle adjustments, learning from the mistakes of others, abandoning non-working ideas, and building new relationships. Or they were simply in the right place at the right time. (Maybe that "or" should be an "and"...)

Not being willing to fail is a curse for the clever. Clever folk aren't used to failing as a natural occurrence, since the contrived educational system only puts solvable problems in front of students. Worse, they're usually clever enough to figure out to how to stay afloat in difficult seas when sinking and starting over might be a shorter path to success.

Note that I'm not advocating giving up easily or failing spectacularly. Rather, I'm advocating failure in small, frequent, and controlled doses as means of iterating toward a successful outcome.

Howard Foster, Sebastian Uchitel, Robert Chatley, Jeff Magee, and Jeff Kramer at Imperial College London have released an Eclipse plugin that performs verification operations for BPEL4WS 1.1 processes and WS-CDL descriptions by constructing corresponding labeled transition systems (LTS). (Kramer and Magee wrote Concurrency: State Models and Java Programs about general applications of LTS techniques in Java.) It would be interesting to see how the PXE compiled representation and the FSP version of the WS-Engineer representation compare, but I have my doubts that I'll get a chance to play with it.

0xDECAFBAD — or so they say, and it certainly tastes that way... (Via /..)

Via Charles Dietzel and others, the upcoming Java Studio Enterprise contains BPMN tooling and integration with PXE! The getting started guide for BPEL functionality has some nice screen shots and a walkthrough of a classic travel reservation example process.

I've moved the venerable pbblog over to typo on lighttpd (and renamed it mult.ifario.us), and the experience has been pleasant so far. (Thanks to Joseph Tam for helpful how-to articles here and here.)

The subject matter should stay mostly the same, i.e., whatever I feel like posting. As for migrating away from WordPress, the hosting company (TextDrive) supports both PHP and Ruby, so it's not an absolute imperative. Nonetheless, I'd rather experiment with RoR than muck around with PHP. The one and only experience that I've had with PHP was modifying WordPress to correctly report the content type and deal with the combination of encoding as declared in the HTTP response and the RSS feed. It could have been a property of the version of WordPress (1.2 at the time, I think), but I felt kind of dirty afterwards, the same way that I feel after writing an AppleScript...

The typo distribution includes a convenience script for migrating a WordPress database to typo, and it works well enough. The only hitch in migrating articles from the old WordPress ID-based permalink scheme is that typo article numbers are allocated sequentially based on the number of published articles, while WordPress doles out IDs based on when the draft for the article was created or when the article was published, whichever came first. Since some drafts remain unpublished, WordPress thinks that I have 128 articles with some gaps in the IDs, while typo thinks that I imported 121 with no gaps in the IDs. It should be a quick exercise to cook up a controller to map the old IDs to new IDs. At some point, I'll get the rest of the content from the Radio and SnipSnap incarnations of pbblog imported as well.

I'm a fan of thick clients for web applications, even those with front ends that would be nice by web or even Web 2.0 standards. I'm not going to trade my OS in for a browser anytime soon.

Like TimTam for Confluence, I'm enjoying 1001 as a non-browser front-end for uploading to Flickr — drag an image or two over from iPhoto, select a couple of tags, type blurbs, hit "Upload", and it's done.