long running process

Nov 02, 2010

Today, Jim and I paired for the day working on an issue involving a long running process. We ended up placing a bunch of log messages around code on the server and client side as well as using the logs generated by the Rails app. After some time, we were able to narrow it down to a server side process. Fortunately, it was not an issue with the webservice, but a long running process occurring on the server side. The process took longer than the client's timeout and the client disconnected. Here are some things I've learned from the troubleshooting process:

Trace logs don't tell you the whole truth

While this may be obvious, the details of the log did not exactly spell out the exact problem. It did a great job of pointing out the vicinity of the problem though. By placing a bunch of log messages around the area in the code, we were able to pinpoint the problem.

Communication is important

Another obvious one, but wanted to note the importance of communication. With the help of both Erics, we were able to pinpoint the problem. We all worked on it together and found the problem. It was great to have other developers next to you to help you out when needed.

Rinda Server/Client and Tuples

I heard Jim and the Erics use these terms a lot in conversations, but did not know what they were. Now I understand the terms and context used in this project. It's a neat way of managing tasks and/or background jobs. I'm not sure where the statemachine fits in to the scheme of things, but Rinda server/client reminds me of the socket service I implemented in my HTTP server and tuples are like messages that represent things that need to get done.

Testing Tasks are Hard

While I'm getting more familiar with unit (or micro) testing and TDD, I've not tested tasks before. In a previous Rails project, I created a Rake task, but did not create a test for it. There's something difficult about creating tests around a single command that does a lot of things. Of course, the individual methods have been unit tested, but integration like tests is a different story. I followed Jim's lead and learned his approach to the problem. While we did not finish by the end of the day, it was interesting to see how it was created.

Next Up

I'll be pairing with Eric Meyer today. We are taking the train down to the Chicago office and will attend the Ruby meetup afterwards. I look forward to learning more about the project.