Blogging Techstacks

Apache 2.2.9 Released

Late last week, the Aache httpd project released version 2.2.9 of the apache web server, which fixes a couple of mod_proxy vulnerabilities as well as addressing some outstanding bugs. Here is the link to the changelog. No one really blogs about apache any more--at least none of the blogs I regularly visit. Interestingly, only one or two sites tracked by technorati made mention of it. I'm not really sure why this would be the case given that this web server is used on about 50% of the sites that you might be visiting today. An interesting parallel exists for me at work. When all the change orders for a new web app are compiled by a development team, the mod-proxy or mod-jk changes to expose this new app to the Internet are consistenly forgotten. Poor apache--your success and ubiquity has transformed you into just another "plumbing" component alongside ethernet and tcp/ip and dns. At least in the j2ee world I live in, apache is quickly becoming one of those things that is just 'there'--another component of the 'ping' in 'ping, power, and pipe'.

Déjà vu

Is it just me? Lately at work, many different applications all seem to be suffering from the same issue--the app works fine until it's deployed into production. Once you put that firewall between your public-facing web servers and the app and db servers, all sorts of interesting problems arise. I think it's the fault of the vendors and the open source framework and app servers developers. In the mad grab to become number one within a particular realm, almost no time is spent on the operational aspects of that particular piece of technology. You can read many cases where someone developing a particular app or function will say, "Don't do this in a production environment. This is here simply for illustrative purposes only" without ever really dedicating any bits to things you will need to change if you are going live or deploying across multiple tiers.

Just this past week, I had to remind some developers that Log4J allows you to change logging levels within an application from ERROR all the way down to DEBUG on-the-fly. After much internal debate, instead I get an updated log4j.properties file that they asked me to change within their web app and then restart tomcat.

Also, within the past two weeks, I've had two separate discussions with two separate development groups working on two completely unrelated applications in regards to connection pooling. To reiterate for anyone reading this, "It is not the responsibility of the DBMS to manage the client's connection pools!". Six years ago we were doing this with asp and sqlserver developers and now I'm doing it again with jdbc and oracle developers. It doesn't matter to me how you do it but if you develop something that is particularly robust, share it with the rest of the organization so they don't need to reinvent the wheel. If you open a connection, close it. Check it first to see if it's OK. If you create a pool, time it out after a certain period of time otherwise your firewalls will sever the connection for you.