Thoughts and Ramblings

This is the first is a series of blog posts I’m going to write over the next several days on things that Objective-C can learn from Java. I’ve been programming in Java since 1997, and in Objective-C since 2001. The two languages have a lot of similarities, but there are a few design principles in which Java excels and Objective-C is left behind. This is understandable considering that Objective-C is older than Java, and Java borrowed heavily from Objective-C when it was designed. In this series I’m only going to discuss changes to the language; these items will have very little, if any, impact on the runtime. For the purposes of this discussion, I’m going to use Java’s terminology since it is more familiar with the programming public. This means I’ll talk about functions instead of selectors, and interfaces instead of protocols.

I’ve been slowly transitioning to using nginx as the web front-end in an effort to reduce Apache’s memory usage. In keeping with this task, I’m moving more and more off of Apache. One piece I recently moved was trac, transitioning to using it directly by nginx by running it in fast-cgi mode where as previously it was running as cgi though Apache.

While fast-cgi is faster, it has inherent issues, such as any memory leak can result in ever growing memory usage, which is exactly why Apache has a setting for each child to serve a limited number of requests before exiting. Trac.fcgi has no such directive, and has the equivalent of a large memory leak, a non-expiring cache. While it’s not as bad as a memory leak, which will indefinitely grow instead of reaching a limit, if the cache size is larger than the available memory for trac to use, it’s just as serious. The only solution, without fixing trac’s caching mechanisms, is to restart trac periodically, but during the time trac is restarting, all requests are lost, causing bad gateway errors to the user. Additionally, the restart needs to be done manually. Clearly not an ideal solution.