FreeBSD Decaf September 4th, 2003
I've received some horrified responses to my post on J2EE Applications on Wintendo Servers. Why on earth is a FreeBSD committer not fighting tooth and claw to put FreeBSD on a production host instead of Wintendo 2000 Swerver?
Quite simply, FreeBSD is only available in decaf; it lacks the kind of hard-hitting Java support that fuses your vertebrae, staples your eyelids to your face and performs real-time edge sharpening on your visual input.
This applies to both branches of FreeBSD (4.8-STABLE and 5.1-CURRENT), but for different reasons:
-
The stable branch of FreeBSD emulates threads in user space. Only one process (or emulated thread within a process) is allowed to "descend into" the kernel (technically "execute in privileged mode") at any given time. This restriction is enforced by a single, global lock affectionately referred to as The Big Giant Lock (as opposed to The Little Giant Lock, pulling faces at us through the looking glass).
-
The development branch of FreeBSD uses fine-grained locking to mediate concurrent access to sensitive kernel data, so it's possible for multiple threads to execute in privileged mode at the same time. That's great. Unfortunately, the process of locking down the various kernel subsystems with fine-grained locks and removing them from under Giant represents an enormous amount of work, and that work isn't finished. The end result is that the development branch is significantly slower than the stable branch.
The bottom line is the same for both branches; highly threaded applications just won't scale on FreeBSD right now. J2EE applications are almost always highly-threaded for any serious production deployment. FreeBSD is fine for a Java developer; that's where I do all my development and testing work, including testing JBoss and Tomcat deployment and execution. But production? Forget about it.
And I'm not just passing on hearsay. I actually tried FreeBSD as an alternative to Wintendo for this deployment. Using the native 1.4.1p3 JDK on FreeBSD 4.8-STABLE, instantiating 2,000 concurrent Tomcat processors would result in an indefinite CPU spin. On 5.1-CURRENT, that number of processors worked, but far too slowly.
It's important to keep in mind that what I've said above has a limited shelf-life. Sooner or later, a FreeBSD release will come along that will invalidate everything I've said above. Even so, I still wouldn't have deployed on FreeBSD if we were already there. Nor on Linux, which already is there.
Why? Pragmatism, something that's seriously lacking in many Unix circles.
The technical lead on the project is most familiar with the Wintendo environment. He has a strong background in Microsoft SQL. While the SQL code used in the project is relatively RDBMS-agnostic, he recognizes that in the early days of production deployment, he's going to be fiddling a lot. He'll be fiddling with the database and he'll be fiddling with application configuration files.
Will it eventually make sense to deploy on a serious operating system? Definitely. But it doesn't make sense right now. In the throes of the product launch, most of the problems encountered are likely to be in the application itself. So what the technical lead most wants is to be freed up to focus on the application. The best way to facilitate this is to host the fledgling application on a familiar platform. As the focus of attention shifts down through the software stack, it will make more and more sense to consider moving to a serious platform, albeit unfamiliar.
Those who know me, know that I'm a vocal Microsoft detractor. Not only do I believe that the corporation produces shit software, I believe they no longer have a grip on any key area of the industry and won't even constitute a blip on the radar in a decade. But I respect the decision of the technical lead. It's a pragmatic one, and it makes.
For now...
hi there, I was playing kinda your role in a team last year when most of the team including the 2 tech leads weren't quite familiar with linux. (But the architect was very familiar with linux.) But that did NOT prevent us from deploying(only tomcat) on linux. as far as searching config files and logging, we trained them on winscp/putty and samba. Things were just fine. It also helped that the previous windows load testing was very unstable experience. As soon as they saw a stable environment, they jumped aboard -- knowing that we(those who know linux) would be able to help them out tracing issues. BR, ~A