IMO - ASF

The Path to Apache OpenOffice 4.2.0

nospam@example.com (Jim Jagielski) — Mon, 04 Dec 2017 07:57:45 -0500

It is no secret that, for awhile at least, Apache OpenOffice had lost its groove.

Partly it was due to external issues. Mostly that the project and the committers were spending a lot of their time and energies battling and correcting the FUD associated around the project. Nary a week would go by without the common refrain "OpenOffice is Dead. Kill it already!" and constant (clueless) rehashes of the history between OpenOffice and LibreOffice. With all that, it is easy and understandable to see why morale within the AOO community would have been low. Which would then reflect and affect development on the project itself.

So more so than anything, what the project needed was a good ol' shot of adrenaline in the arm and some encouragement to keep the flame alive. Over the last few months this has succeeded beyond our dreams. After an admittedly way-too-long period, we finally released AOO 4.1.4. And we are actively working on not only a 4.1.5 release but also preparing plans for our 4.2.0 release.

And it's there that you can help.

Part of what AOO really wants to be is a simple, easy-to-user, streamlined office suite for the largest population of people possible. This includes supporting old and long deprecated OSs. For example, our goal is to continue to support Apple OSX 10.7 (Lion) with our 4.2.0 release. However, there is one platform which we are simply unsure about what to do, and how to handle it. And what makes it even more interesting is that it's our reference build system for AOO 4.1.x: CentOS5

Starting with AOO 4.2.0, we are defaulting to GIO instead of Gnome VFS. The problem is that CentOS5 doesn't support GIO, which means that if we continue with CentOS5 as our reference build platform for our community builds, then all Linux users who use and depend on those community builds will be "stuck" with Gnome VFS instead of GIO. If instead we start using CentOS6 as our community build server. we leave CentOS5 users in a lurch (NOTE: CentOS5 users would still be able to build AOO 4.2.0 on their own, it's just that the binaries that the AOO project supplies won't work). So we are looking at 3 options:

We stick w/ CentOS5 as our ref build system for 4.2.0 but force Gnome VFS.
We move to CentOS6, accept the default of GIO but understand that this moves CentOS5 as a non-supported OS for our community builds.
Just as we offer Linux 32 and 64bit builds, starting w/ 4.2.0 we offer CentOS5 community builds (w/ Gnome VFS) IN ADDITION TO CentOS6 builds (w/ GIO). (i.e.: 32bit-Gnome VFS, 64bit-Gnome VFS, 32bit-GIO, 64bit-GIO).

Which one makes the most sense? Join the conversation and the discussion on the AOO dev mailing list!

Apache httpd Reverse Proxy

nospam@example.com (Jim Jagielski) — Tue, 26 Jan 2016 08:23:01 -0500

I've always considered the reverse proxy capability of Apache httpd as one of the real (hidden) gems of the web server. Of course, httpd has a lot of gems: multiple MPMs; a plethora of content creation and rewriting capabilities; dynamic loadable modules; performance and concurrency easily matching its peers; in-depth Lua, Perl and PHP support; and, of course, the vast number of external, 3rd party modules out there. But, for me, the reverse proxy has always been one of its crowning achievements.

So even though Apache httpd excels at delivering both static and dynamic content, an extremely common use-case is for httpd to be used as a "simple" reverse proxy (aka: "gateway"). In this scenario, httpd acts basically like a switch, accepting requests but handing those requests off to servers on the backend. Those backend servers ("origin servers") are where the content really lives, or is created, but the outside never sees them; never even knows they exists. As far as the Web is concerned, that front end gateway is sole server.

The advantages of this setup are numerous and obvious; The implementation provides for high-availability, load balancing, failover, reliability, etc... but only if the gateway web server, the reverse proxy itself, has that capability. Fortunately, Apache httpd does. It has all that and more.

Because it is such a common use-case, and because this capability to so vital to the design and architecture of enterprise web infrastructure, including Cloud setups, I've focused a lot of adding features and improvements to httpd's reverse proxy. Along with the other committers on the httpd project, not only has load balancing been added (and has been for quite awhile), but there are various load balancing methods included, with the ability to add your own implementation very easily. With the balancer-manager, the devops admin gets not only a view into the current state of the reverse proxy, but can also dynamically change various reverse proxy parameters on-the-fly, with these changes surviving a server restart. The reverse proxy supports not only HTTP, but also FastCGI, Websockets, AJP and others. And just recently, I finished work on something that has been on my TODO list for awhile, and something people have wanted for awhile as well: Dynamic Health Checking.

In the normal situations, before httpd sends a request to the backend origin server, it checks to see if it is still "alive" and able to handle the request. Now this is great but it would be even better if, in parallel, httpd was also checking if those backend servers were alive or not independent of requests being passed to them. In other words, not only static health checks but also dynamic checks as well.

Well, now Apache httpd can do exactly that.

Right now this capability exists just on the trunk branch of the server, but I anticipate it being fast-tracked backported to the 2.4.x branch. There are also some addition features I'd like to add in, such as better interaction with the balancer-manager before it is backported. But before too long, the Apache httpd reverse proxy will have this capability and be even better than it is now, and continuing to be even better than its peers, whether they are Open Core or commericial or truly Open Source.

Try it out! And if you are interested in helping develop Apache httpd, jump in and join the fun. Unlike other web server projects, contributor and commit privs can obtained by anyone, not just specially picked people, like "employees" or stuff.

Help Jamal Learn Coding

nospam@example.com (Jim Jagielski) — Wed, 16 Dec 2015 08:59:00 -0500

OK, so my house is basically the official address for the Apache Software Foundation. If you check out the address for the ASF on various documents, as well as our D&B listing, it'll refer back to my old homestead. This is because back when we founded the ASF, out of the Apache Group, we needed to list some address on our records, and since I had basically just moved, my address seemed the most stable. And then, after serving initially as EVP and Secretary, those roles kind of cemented my address as the canon location for the ASF.

Over the years this has resulted in a variety of interesting situations, such as random people coming up to ask for job openings, taking pictures of "Apache HQ" and even numerous visits by the FBI as they investigate various web-related issues. But this also means that I receive a lot of postal mail directed to the ASF as well, and these are just as interesting. There are the numerous requests for help, letters demanding to know why this "Apache stuff" is on their devices and demands that we stop installing our "junk" on their computers, and the occasional "Thank You" letter from someone truly appreciative and what we do.

And very rarely, a letter which calls me to action.

I received such a letter this week.

The letter was from Jamal Reid, an inmate at the State Correctional Institution at Dallas in Pennsylvania. While serving his time, he is trying to learn programming and the selection of books available to him are woefully out of date. He sees programming, and career as an Application Developer, as his ticket out from a criminal life. He wants to learn and he wants to be a viable candidate, with the necessary skills, for a job in programming once he completes his sentence. All he asks is that, if possible, if we could "donate a few books" to help.

Well, I already have a box of books ready to ship out. But I am reaching out to everyone who follows me, or also believes in the power of community within the Open Source eco-system, to also donate what books you can. During this time of year, one of the most cherished stories is A Christmas Carol, a tale of redemption. Let's share the potential of that redemption.

Let's #HelpJamal.

His address is in the letter linked to above, and I strongly encourage you to read it. I also include it here to make it even easier.

Jamal Reid
GF6119
State Correctional Institution
1000 Follies Rd
Dallas, PA 18612

Being the Old One

nospam@example.com (Jim Jagielski) — Thu, 23 Apr 2015 08:00:00 -0400

This may come off as "sour grapes", or being defensive, but that's not that case. Instead, it's to show how, even now, when we should know better, technological decisions are sometimes still based on FUD or misinformation, and sometimes even due to "viral" marketing. Instead of making a choice based on "what is best for us", decisions are being made on "what is everybody else doing" or, even worse, "what's the new hotness." Sometimes, being the Old One ain't easy, since you are seen as past your prime.

Yeah, right.

Last week, I presented at ApacheCon NA 2015, and one of my sessions was "What's New In Apache httpd 2.4." The title itself was somewhat ironic, since 2.4 has been out for a coupla years already. But in the presentation, I address this up front: the reason why the talk was (and is) still needed is that people aren't even looking at httpd anymore. And they really should be.

Now don't get me wrong, this isn't about "market share" or anything as trivial as that. Although we want as many people to use Apache projects as possible, we are much more focused about creating quality software, and not so much about being a "leader" in that software space. And we are well aware that there are use cases where httpd is not applicable, or the best solution, and that's great too.

First of all, there is still this persistent claim that httpd is slow... of course, part of the question is "slow how?" If you are concerned about request/response time, then httpd allows you to optimize for that, and provides the Prefork MPM. Sure, this MPM is more heavyweight, but it also provides the lowest latency and fastest transaction times possible. If instead you are concerned about concurrency, then the Event MPM is for you. The Event MPM in 2.4 has performance equal to other performance-focused Web Servers, such as Apache Traffic Server and NGINX. Even so, whenever you hear people talk about httpd, the first thing they will say is that "Apache is slow, where-as 'foo' was built for speed."

There is also the claim that httpd is too feature-full (or bloated)... Well, I guess we could say "guilty as charged." One of the design goals of httpd is to be a performant, general web-server. So it includes lots of features that one would want, or need, at the web-server layer. So yes, it includes caching, and proxy capability, and in-line content filtering, and authentication/authorization, and TLS/SSL (frontend and reverse-proxy), and in-server language support, etc... But if you don't need any of these capabilities, you simply don't load the modules in; the module design allows you to pick and choose what capabilities you do, or don't want, which means that your httpd instance is specific to your needs. If you want a web-server with all the bells and whistles, great. But if you want just a barebones, fast reverse proxy, you can have that too. Of course, I won't go into the irony of httpd being "blasted" for being bloated, while the hotness-of-the-day is praised for adding features that httpd has had for years. *grin*

Finally, we get to the main point: That Apache httpd is old, after all, we just celebrated our 20th anniversary; httpd is "old and busted", Foo is "new hotness"(*). Well, again, guilty as charged. The Apache httpd project is old, but httpd itself isn't. It is designed for the needs of today's, and tomorrow's, web: Async/event-driven design (if required), dynamic reverse-proxying with advanced load-balancing (and end-to-end TLS/SSL support), run-time dynamic configuration, LUA support (module development and runtime), etc...

You know what else is old? Linux.

Makes you think, huh?

The Case for a Universal Web Server Load Value

nospam@example.com (Jim Jagielski) — Mon, 12 Nov 2012 10:00:00 -0500

The reverse proxy feature of Apache httpd is an area which I like to particularly hack on. It's always been, imo, one of the killer features of httpd, but it is especially useful in the Cloud. Being able to dynamically allocate, enable/disable and load balance between back-ends is a MAJOR capability lacking in almost all other "generic" (and even "special-purpose") web servers. And the functionality of the reverse proxy in Apache 2.4 is pretty much state-of-the-art.

But there's a problem, which is not unique to Apache itself. In general, load balancers such as Apache do their load balancing determination based on values it calculates on the back-ends. Sure, Apache has a pretty nice set of load-balancing algorithms, but it still implies that the front-end (the reverse proxy) is responsible for predicting the load on the back-end. This is certainly not optimal.

Red Hat's mod_cluster works around this by creating a "unique" communication channel between Apache and JBoss, which allows JBoss to tell Apache some basic and useful loading parameters on the JBoss server itself. This is great, but limited (and hardly universal). What we really need, imo, is a general, universally agreed-upon method of the back-end sending server load data to the front-end. Something that all back-ends can easily generate (and enable/disable, of course) and something all reverse-proxies can easily parse and use. In other words, we need some sort of unofficial standard (which could eventually become a de-facto standard).

Using the assumption that starting simple is best, what I've been looking at is adding a simple HTTP Response header to Apache (via mod_header) which returns some subset of load parameters, the idea being that when the back-end sends the actual response, part of the meta-data it returns is some measure of its health and/or load. The front-end can then tuck that data away and use it in its load-balancing determination (while, of course, ensuring that the header is not forwarded to the client). Currently, in the trunk version of httpd (but hoping to backport it to 2.4), I have traditional Unix-type load-average and the percentage of how "idle" and "busy" the web-server is. But is that enough info? Or is that too much? How much data should the front-end want or need? Maybe a single agreed-upon value (ala "load average") is best... maybe not. These are the kinds of questions to answer.

Knowing that Apache httpd powers between 57% and 89% of the web (based on which surveys you use and/or trust), it seems logical to discuss this, and work out the particulars, on the Apache httpd development mailing list. I think the time for something like this "universal web-server load" value is long overdue. If interested, join the fun on dev@httpd.apache.org.

The silent drum-beat

nospam@example.com (Jim Jagielski) — Mon, 28 Nov 2011 23:04:00 -0500

There are some topics which are just too expansive for a simple tweet. This is one of them.

Lately, there have been quite a few posts extolling the assumed decrease in the viability and "reason" for the Apache Software Foundation. It's always fashionable to lump all FOSS foundations, and related entities (such as Github), into one combined group and pick out the "winners" and "losers" and those whose stars are rising and those whose glory days are fading away. With the hubbub around DVCS and git/Github, people look at the ASF, and our measured approach to incorporating git into our workflow policies, and declare that since we have not drank the Kool-Aid, the ASF's days are done.

But all this misses the point about what the ASF is, and who we are, and why we are. I hope this blog post will clarify some things.

Continue reading "The silent drum-beat"

Apache httpd 2.4 - one step closer!

nospam@example.com (Jim Jagielski) — Mon, 07 Mar 2011 09:05:19 -0500

Today we released the first public beta of the next-gen version of Apache httpd, version 2.4. This release is officially called Apache httpd-2.3.11-beta, since we use odd/even numbering (for the minor version number) to signify alpha/beta vs. stable releases. Most work has been done in improving performance and stability, but as well as adding lots of useful features, especially as we see the demands placed on web servers by cloud environments. This means that the (reverse) proxy module had gotten a lot of special care and attention. But there are also modules to help with more fine-grained control over timeouts and even a basic bandwidth limiting module bundled in. With this release and the coming of Apache httpd 2.4 GA, you'll see the popularity and usage of Apache increase even more, as it becomes the web server for the cloud, bar none. Cheers!

The JCP Is Dead

nospam@example.com (Jim Jagielski) — Thu, 09 Dec 2010 15:16:48 -0500

... and Oracle killed it. By this time, most people know that the ASF has resigned from the JCP EC. What was posted was our final version of the notice, but I'd also like to share with the community an earlier, rougher and more "emotional" version. It says the same, but in a more face-to-face conversational way. I feel that both versions represent the disappointment, anger and sadness over this whole issue, which has been fostering since 2006. The below just captures it from a different point of view:

The Apache Software Foundation is resigning from the Java Community Process (JCP) Executive Committee (EC). On December 7, 2010, by a vote of 12 YES and 3 NO votes, the EC approved the Java 7 and Java 8 JSRs and TCKs under license terms which are fundamentally incompatible with open source. The results of the Java7/8 JSR votes from yesterday mean that the EC has just approved a major fundamental JCP specification which, along with its TCK license, makes distribution of a tested, compatible implementation impossible under *any* open source license by anyone other than Oracle. The EC, by voting in favor of the Java 7/8 JSRs, have given Oracle, who openly ignored the letter of the law as well as the repeatedly stated intent of the community, tacit approval to willfully ignore its contractual obligations, despite any "protests" within their "YES" vote comments. This approval was at the direct expense of a fellow EC member as well as the Java community at large. Yesterday's vote is the final straw in an issue which has been ongoing since August 2006 and as described in our Open Letter dated April 10, 2007. The withholding of an acceptable, FOU-free TCK by Sun, and now Oracle, is against both the spirit and the letter of the JSPA. What is not new is that Oracle continues to violate and not honor the JSPA agreements, which are a foundation of the JCP. What *is* new is that the EC, by fact of their vote, has allowed them to do it. It is obvious that the JCP is not a standards forum, nor a community process at all, but rather a cabal to control the Java ecosystem. The ASF can no longer justify its continued involvement within this entity. As such, the ASF is removing all official representatives from any and all JSRs. In addition, we will refuse any renewal of our JCP membership and, of course, our EC position. The ASF is saddened to have to make this move, but we feel that the JCP is completely broken and makes a mockery of the term "community," a concept which has great value to Apache.

Of course, we had hoped that our previous blog post would have spun up more support, but being the pragmatists that we are, we also knew that the other EC members were being seriously pressured by Oracle to vote YES, and so we held out little hope. We also hoped for a better response from Oracle, but what we got was basically self-serving lip-service with what is most likely the funniest and yet most inaccurate line yet in the whole ordeal:

"Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA."

If that little nugget doesn't show that Accuracy and Oracle don't mix, I don't know what will. The JSPA says, in 5.C.III, that a spec lead can't:

"impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations"

and, of course, the FOU restriction does exactly that. And as far as "non-discriminatory", well, Oracle has deemed that OpenJDK (*their* distribution) not have any FOU restrictions on the TCK, but that the ASF's (Harmony) will. And that isn't discrimination? And so, the JCP is dead... All that remains is a zombie, walking the streets of the Java ecosystem, looking for brains... But maybe, from this death, a new, true community process might arise somewhere, with a different collection of people, one with no entity "more equal than others". That is something I think the ASF would be quite interested in seeing.

Language diversity

nospam@example.com (Jim Jagielski) — Tue, 21 Sep 2010 09:35:30 -0400

If you look at the projects within the ASF, you'll notice right off the bat that the vast majority are Java. We do have a handful of other projects based on other languages but, for better or worse, most of 'em are Java. But if you look at the code that *powers* the ASF you'll notice a big difference. For one thing, for the most part, we do not run anything that requires a JVM (well, we prefer not to). Also, we prefer all of our sites be as static as possible, which makes mirroring them easier. But the biggest surprise might be just how much we use scripting languages for all the tasks/applications/tools that we need. We use a suite of Perl, Python and Ruby, with Perl being the clear frontrunner (mostly since JoeS is such a Perl monger). What I think is so useful about all this is that it gives a true, clear perspective on how real infrastructure is architectured (my word). People tend to focus, unjustly, on the applications themselves, and give little thought or credence on the infra required to truly support and implement all that. And this skewed perspective can easily result in bad, dangerous mistakes when making the transition from one architectural design to another, because it ignores a big, big part of the puzzle. As people look at, investigate and migrate into the cloud, this will become even more of an issue. And a concern.

Apache HTTP Server 2.3.8-alpha

nospam@example.com (Jim Jagielski) — Tue, 31 Aug 2010 10:40:04 -0400

Today, I (as Release Manager for the project) released the latest, and what is expected to be the last, alpha version of the NextGen release of Apache httpd. This is pretty exciting news because for now on we'll be focusing on pushing out beta releases in anticipation of a quick trip to 2.4.0-GA. Certainly, Apache httpd 2.4.0 has been a long time coming, but it will be well worth the wait. The new features, especially related to MPMS, Authn/Authz and the Proxy module, will continue to be the reference standards for web servers. I'm really excited by all the mod_proxy improvements because that's an area which I, and others, have been giving special attention to. You combine that with the various async changes, the Event and (for the time-being still experimental) Simple MPMs and you have a killer server. So download and try it out and give us your feedback. Cheers!