httpd 2.2.17 has been in the atomic-testing repo for over 6 months now, and except for a few module issues I havent heard any show stoppers. I would like to propose standardizing atomic on the 2.2.17 branch of apache, so now is the time for public comment. (And for php 5.3, that will probably go up today)

Please voice your opinions & observations on this change, I'd like to have a decision by the end of the month.

Is there an upgrade guide on the wiki like with PHP and MySQL? Or is "yum upgrade httpd" all you need to know?

Has anyone some experiences about the performance of 2.2.17 compared to the default 2.2.3?
Or any other changes worth knowing about?

For reference: http://www.apache.org/dist/httpd/CHANGES_2.2

We'll do the same thing for apache. There will be a wiki page just like the PHP and Mysql ones with any extra steps (there are some deprecated modules for example) you'll have to do.

What are the features for which we would want to have 2.2.17? I like to use vendor supplied packages as much as possible, since I feel they are more thoroughly tested and I like that they aren't moving so fast. For PHP I see the use of upgrading (clients asking for more recent versions because they want to use features only available in later versions), but I'd even rather stick with the vendor supplied MySQL packages for instance. I haven't felt the need to try Apache 2.2.17 from atomic-testing yet.

If upgrading Apache is optional, I'm not against putting it into atomic, but I probably will stick with the vendor packages. If other packages are going to depend on the newer Apache, well, I'll just have to play along.

One thing we've seen with the Apache 2.2.17 is that the segfaults caused by a bug in APR go away. So theres that.

The deprecated modules should normally give a clear error when restarting Apache
Are there any other important things? Anything about Plesk? According to http://kb.parallels.com/762, it should recognise the upgrade automatically.



MySQL 5.1 and 5.5 are adding a lot of features too. Though small users won't use them yet. And there are also a lot of performance improvements, as there's the competition of Drizzle, MariaDB and Percona.

Apache is getting competition from Litespeed, lighttpd and nginx which are faster, more lightweight solutions. And the first beta of Apache 2.3 was released a couple of days ago.

The only major plesk collision I can think of would be on CentOS/RHEL 4. But we cant do apache 2.2 for that environment anyway (Plesks configs dont work with 2.2) so its a non issue.

Sounds to me like something that should be reported to and fixed by the OS vendor. I haven't experienced that problem myself by the way, so it wouldn't be a reason for me to upgrade.

Is this the bug that's been hitting me? Has it been identified at long last as being caused by APR then? Or it is just one known bug and my problem could still be being caused by almost anything?

I'd assume it is APR, so far every backtrace I've seen the cause was APR, and you can always rollback to an older Apache if that doesnt solve the problem for you. I suggest you give it a shot, you should be fine with the newer Apache.

Unfortunately all our affected systems are RH4.

The move to RH5 (or even 6) will be painful as we'll have to Migrate 300+ plesk accounts from 8.6 to 10. It won't be fun so although it is on the cards it isn't scheduled for anytime soon.

Faris.

I tinkered some with the ITK module that was built in. Never got it working satisfactory for production so we dropped it. Saw no performance gains or anything under 2.2.17 (and I thought that it was dead since Scott said mod_sed was replacing ITK).

I am neutral in making it the default.

Yeah, in that case given the age of the code in RH4 APR is almost certainly the cause of your segfaults. A lot of bugs have been fixed in Apache since 2.0, and we know of segfault issues in APR.

EL4 is still supported, so if these are reproducable issues then reporting them would make sense, right? Or has this already happened?

mod_ruid2 would be the module equivalent of ITK.

breun- its not a bug so much as a design limitation of 2.0. The only way to get past it is to use the 2.2 architecture.

Anyway, this thread is about apache 2.2.17 and adopting it in the repo. So lets keep the discussion on this topic.