Apache 2.2.0 Released

ikewillis writes "According to an announcement on apache.org, Apache 2.2.0 has been released. From the announcement: 'This version of Apache is a major release and the start of a new stable branch. New features include Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.' View the ChangeLog or check out the new feature list."

Comments

Great Job ASF

[webperf]

A round of thanks to all the hard work done by the HTTPD team.

you guys ROCK

and special thanks to paul who pushed this through!

Inertia

[code65536]

That's interesting how they jumped from the 2.1.x beta versions to 2.2.0. They didn't do this when they went from the 2.0.x beta to the 2.0.x stable (hence the large .55 attached to 2.0.x right now). It's kinda like what Perl does with having devel and stable versions have odd and even numbers, respectively.

Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy ;)), I have this feeling that we might see the same 1.3->2.0 inertia.

Re:Inertia

[Floody]

Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy ;)), I have this feeling that we might see the same 1.3->2.0 inertia.

The change from 1.3 -> 2.0 was a very major one. The entire api was retooled; and for good reason, ap 1.3 had some rather serious deficiencies in the extensibility department (module load order significance, etc). 2.0 saw the birth of the exceedingly well designed APR (Apache Portable Runtime), a module-participation-driven abi ("hooks") and fast stack-unwinding i/o handling ("fitlers"). All good stuff, but slightly less able performance-wise on low-cpu-count hardware (extensibility always comes with a pricetag) and completely imcompatible with any module of even moderate complexity that had previously been written.

Times have changed though. The robustness of the abi design combined with the APR has led to some outstanding modules, such as extensive state awareness and dynamic load-balance adjustment without even USR1-style interruption. None of these capabilities are even remotely plausible under 1.3.

The point is: 2.2 is still the same core api design. Certainly, it contains some enhancements, but the bridge that must be crossed is miniscule in comparison to the 1.3/2.0 transition.

There is still much room for improvement (when isn't there?). For example, mpm looks like a good idea on paper, but how well does it really work in terms of abstracting the process/thread semantics into fairly "pluggable" components? How well can it really work? Thread-based design requires a completely different approach or the end result (treating threads like processes) simply nets you more "accounting" overhead and few significant gains to offset that (yes, I realize it wins on win32 which does not have a light-weight process model).

Re:Can reconfigure without restart NOW

[Matt Perry]

Actually you want SIGUSR1. HUP does a regular restart which will cause any children to terminate immediately. Any requests in progress are terminated. USR1 (graceful restart) will allow the child processes to finish serving their requests and newly spawned children will have the new configuration.

See the docs on stopping and restarting for reference.

Re:Can reconfigure without restart NOW

[The Clockwork Troll]

If you plan to rely on graceful restarts, be sure to set MaxChildren appropriately low, proportional to your server request rate, otherwise your config changes will never get picked up.

Re:GUI?

[code65536]

I've used the IIS GUI once because I was curious. *shudder* GUIs are useful only when well-designed.

1/ There are Apache GUIs. Google them up. Some are free, some are not.

2/ Opening the config file in a GUI text editor and navigating around with a mouse should be fairly easy, especially with the copious amount of documenation in the config.

3/ It's very difficult to express the rich level of complexity of Apache configurations in a GUI. Just imagine how on Earth a GUI can be made to handle nested VirtualHosts, Directorys, and Files. Throw in some regexp, and suddenly, you are faced with a situation where it becomes a heck of a lot easier to just edit the config file. To say that a GUI is always easier than text is incorrect; it depends on the situation, and Apache configs are one of those situations where this is the case (kinda like how when dealing with non-photographic web graphics, you need to use PNG or GIF and avoid JPG like the plague and how when dealing with photographic web graphics, you have to use JPG... each rules over their own niche of strength).

4/ If a GUI is made, it is highly likely that it won't be as powerful as just using a text editor; it's not as expressive (see above). But there's really not much to do with the basic configuration, either. For the most part, the default configuration works just fine, and if someone needs to edit the settings, it's mostly for the complicated stuff that would be a bloody mess to do in a GUI.

5/ Compactness and portability.

Re:Stick with NCSA HTTPd 1.5.2a

[Mjlner]

"I think I'm going to stick with something I can really trust!

Maybe I'll try CERN httpd 2.14, I'm not sure if 3.0 has enough of a track record."

Running Debian stable, eh?

Re: Version numbers

[rbowen]

In the mean time (ie, since the 2.0 release) we've changed the versioning model to the "odds are dev, evens are stable" model. So as soon as 2.2 released, development moved to the 2.3 branch, which will release as 2.4. So, yes, like Perl and Linux and many other things.

As for transferring >2GB files, this comes up many times every day on #apache, and fairly frequently on the mailing lists, so people do actually want to do this.

Folks that are still using 1.3 are missing out on enormous strides forward. The "it still works fine, why should I upgrade" crowd are completely welcome to remain where they are, and we're not going to compel to move, but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.