Never forget, mod_perl 2 is not done yet. So not only is the coding not finished, but the documentation isnt either. Many of your points of frustration I think stem directly from those 2 facts. Patience is your best bet, it is a major upgrade (as is Apache 2.0 from 1.36).

Soo, what the monks think about mod_perl 2.0? Are you using/testing it? How it's working?

Since most other posters have addressed your individual points very well, I will leave that alone, and just tell you my personal experience with mod_perl 2.

I have been forced to use mod_perl 2 in a production environment for almost a year now. Normally I would never do this, but circumstances actually proved this to be the best option. Let me first explain those circumstances.

We created an application, which ran upon Windows 2000/Apache 1.36/mod_perl 1.0. It creates reports of arbitrary complexity for a database. It ran fine for almost a year, then due to details which I wont bore you with hear, the performance started to radically degrade. The problem is that mod_perl 1.0/Apache 1.36 on Windows is essentially a single-process, single-threaded application. Yes, thats right, a web/application server that can only serve ONE request at a time.

Now, we didn't know this getting into it, and Windows 2000 was not a choice, it was forced upon us. Our experience was with the Unix variants of mod_perl/Apache, it never occured to us that Windows would be all that different. As I said, it ran fine for almost a year, once it started to degrade, we started investigating. After a long discussion with the client (and a rather long unsuccessful attempt at convincing them to switch to Unix) we decided to investigate Apache 2/mod_perl 2 combo as a solution. The client understood the that Apache 2 (at the time) was still Beta, and mod_perl 2.0 was still in development.

We used Apache::compat, but soon choose to converted the nessecary code, and with minimal headache actually got it up and running. The worst part of it all was getting Apache 2.0/mod_perl 2.0 with SSL built and configured properly. We load tested the application, and found a signifigant improvement in the performance, and absolutely none of the performance degredation issue we had before.

Even though it was a beta Apache and mod_perl was still in active development, it was running better than the original, so we released it to production. I was really surprised, but nothing bad happened, everything worked fine. Only once did we have an issue, which turned out to be related more to DBI and Perl 5.8's threads. We fixed that issue in the code, and took the opportunity to upgrade Apache 2 to the released version, and mod_perl to its latest build.

Granted, we did not use any of the new mod_perl 2.0 bells and whistles, and our original app used handlers and not Apache::Registry. But it ported over easily, and has been running fine for almost a year now. In case anyone wondering, its load is not very high (about 20-30 concurrent users at any given time), but it is for a multi-national corporation, and used worldwide. Apparently they love it in the China office :-).

In general I am very impressed with mod_perl 2, in particular its performance Windows. I am very much looking forward to the upgrade, and can't wait for the new features (output filters, protocol handlers, etc etc etc) to be documented and finished. I think it has alot of serious potential.

One quick note, our original app was ported for another client to Unix with Apache 1.36/mod_perl 1.0 about a year and half ago, and has run without incident under the same (and sometimes worse) conditions as the original. *Sigh*, if only they hadn't been soo stuck on Windows.

-stvn