With Apache 2.0 four months past its stable release, developers are beginning to brainstorm the next steps for Apache — including drafting up a “wish list” for Apache 3.0 features, and mapping out a timeline for the release of upgraded features.
As Apache Software Foundation Chairman Roy Fielding told Open Enterprise Trends, “I’m sure there are lots of things that individuals are working on. [But] none of us will come out and say, ‘Well, this is going to be in Apache 3.0.'”
Fielding, even as he insists it’s a bit too early for a full Apache 3.0 feature list, is beginning to agree with other ASF contributors on the merits of adding at least one new feature to Apache — support for asynchronous I/O.
The Benefits of Asynch I/O
Apache developers, such as IBM employee Bill Stoddard, are increasingly interested in Stoddard told OET that it’s really too early to do much more than speculate on what’s in store for Apache 3.0, but he notes that “one feature high on many folks list is an event driven network I/O.”
Apache developers want asynchronous I/O because they say it provides increased scalability for the Apache Web server. So, in cases where Apache servers could be flooded with requests over a short period of time, an asynchronous server would perform better and be able to handle more requests than the current synchronous server, Stoddard and others said.
But for all the advantages in handling load, this kind of architecture can also have its drawbacks. In particular, asynch I/O will have a higher latency, so that servers handling a lower volume of requests might not see any performance benefits.
The How and When of Apache’s Asynch I/O
Even though Fielding agrees that asynchronous I/O is important, and will come to Apache, he predicts that it may even come sooner than Apache 3.0 — perhaps in an interim upgrade to Apache 2.1 or 2. 2.
Whether asynch I/O is a 3.0 or a 2.1 change really depends on the approach developers take to the software. Fielding believes that it could be implemented as a specialized MPM (Multi-Processing Module) for each individual hardware platform. “What generally tends to happen with asynchronous I/O implementations is that they’re good for one and only one platform,” Fielding told OET.
The MPM approach would take advantage of this fact and it would have the added bonus of — hopefully — not breaking compatibility with other Apache modules. “Of course there’s always the possibility that the API that we have for modules has a lot of dependencies built into it that we haven’t discovered are broken yet,” he says.
Covalent Senior Software Engineer and Apache member Bill Rowe told OET that the MPM process model can only take things so far. He predicts that within three months Apache will “pretty much hit the dead end of how much we want to stretch and pull the MPM model without going on to incorporating asynchronous behavior in the server itself.” And that, says Rowe, is “very much a [Apache version] 3.0-type change.”
Rowe says that another 3.0-timeframe change could be Apache’s adopting an XML syntax for its config files. Whether it would replace the old config files or supplement them has not been determined, he added.
And what exactly is a “3.0-timeframe”? Nobody really knows. Fielding reckons that it’s at least a year away, but adds, “on the other hand, I could easily sit down, design a new protocol for the Internet, write an Apache driver that runs it, and call that a release 3.0. And I could do that by November.”